allow building against espeak-ng

[Lone_Wolf]

There are many successes of running oolite with espeak-ng instead of the deprecated espeak .
To name a few : my archlinux aur packages for 1.90 and trunk, mrfibble's fork, mcarans work on MSYS2.

Maybe it's time to for oolite trunk to add support for espeak-ng ?

One way to implement this would be to introduce 2 new options for the build system :

USE_ESPEAK-NG
USE_SYSTEM_LIBRARY_FOR_ESPEAK-NG

Both would be booleans and default to false (for now) .

If a more flexible approach is desired we could use :

TEXT_2_SPEECH_PROVIDER
USE_SYSTEM_LIBRARY_FOR_TEXT_2_SPEECH_PROVIDER

The first would be a combo setting with atleast espeak (default) and espeak-ng as choices.
(Other choices like speech-dispatcher could be added later)
The 2nd would be a boolean and default to false.

[mcarans]

There are many successes of running oolite with espeak-ng instead of the deprecated espeak .
To name a few : my archlinux aur packages for 1.90 and trunk, mrfibble's fork, mcarans work on MSYS2.

Maybe it's time to for oolite trunk to add support for espeak-ng ?

One way to implement this would be to introduce 2 new options for the build system :

USE_ESPEAK-NG
USE_SYSTEM_LIBRARY_FOR_ESPEAK-NG

Both would be booleans and default to false (for now) .

If a more flexible approach is desired we could use :

TEXT_2_SPEECH_PROVIDER
USE_SYSTEM_LIBRARY_FOR_TEXT_2_SPEECH_PROVIDER

The first would be a combo setting with atleast espeak (default) and espeak-ng as choices.
(Other choices like speech-dispatcher could be added later)
The 2nd would be a boolean and default to false.

I think AnotherCommander is beginning changes including this one in https://github.com/OoliteProject/oolite ... transition, the idea being that both old and new builds can run side by side for a while. The espeak-ng change should be added in there for Linux (while on Windows it must be part of a much larger modernisation required that includes moving to espeak-ng). That branch uses this flag:

Code: Select all

#if OOLITE_MODERN_BUILD

[Lone_Wolf]

The commits for that branch suggest it focuses on windows and objc 2.2 .

What I suggested
- allows different settings per platform
ex: linux foo1 , mac mac foo2 , windows foo1 , android foo7

- flatpak & installer builds would probably use oolite provided libraries
- distro packages could choose between using system libraries OR oolite provided ones

The implementation would be in the makefiles and affect mainly the linking stage.

It's not something I made up, but inspired by the method used by https://openmw.org/ to allow using systemwide installed or openmw provided libraries for external deps.
Openmw is an opensource remake of the morrowind engine that also is cross-platform.

see https://gitlab.com/OpenMW/openmw/-/blob ... eLists.txt for details on how they set it up.

[mcarans]

The commits for that branch suggest it focuses on windows and objc 2.2 .

What I suggested
- allows different settings per platform
ex: linux foo1 , mac mac foo2 , windows foo1 , android foo7

- flatpak & installer builds would probably use oolite provided libraries
- distro packages could choose between using system libraries OR oolite provided ones

The implementation would be in the makefiles and affect mainly the linking stage.

It's not something I made up, but inspired by the method used by https://openmw.org/ to allow using systemwide installed or openmw provided libraries for external deps.
Openmw is an opensource remake of the morrowind engine that also is cross-platform.

see https://gitlab.com/OpenMW/openmw/-/blob ... eLists.txt for details on how they set it up.

I think that there would be little reason to retain espeak support for any platform once we transition to the new build (which should support both gcc and clang objc 2.2 on Windows and Linux with espeak-ng). espeak-ng works on Mac too. Do you think it would be still needed?

I can see that having build specific flags for using system libraries would be useful on Linux.

Speaking of CMakeLists.txt I experimented successfully with a cmake version of Oolite on Linux: https://github.com/mcarans/oolite/tree/cmake (for the building part only not packaging). I think using cmake would simplify having multiple configurations.

I'm not sure what AnotherCommander has in mind for the transition branch - perhaps it is Windows only, although the changes in there should also allow Linux to build with Clang objc 2.2 in addition to gcc and allow either espeak or espeak-ng to be linked by changing the linked library in the makefile.

Please go ahead and investigate flags in the makefile (or using cmake).

[Lone_Wolf]

I think that there would be little reason to retain espeak support for any platform once we transition to the new build (which should support both gcc and clang objc 2.2 on Windows and Linux with espeak-ng). espeak-ng works on Mac too. Do you think it would be still needed?

I think having multiple options available would make it easier to update things gradually.

hypothetical example
we have the following 8 targets :
sourcebuilds for windows , linux, intel macs, arm macs
binary builds for windows , intel macs, arm macs, linux flatpak

At some point in time we want to switch from libpng 20 to libpng 30 , but its only been tested on intel macs and windows sourcebuilds.
With the provider option we could enable libpng 30 for those 2 while we keep libpng 20 for the other 6 targets.

[MrFlibble]

At some point in time we want to switch from libpng 20 to libpng 30 , but its only been tested on intel macs and windows sourcebuilds.
With the provider option we could enable libpng 30 for those 2 while we keep libpng 20 for the other 6 targets.

Current Ubuntu setups use libpng16, against which I build successfully on my fork. This means when I build on the oldest currently supported Ubuntu, the resulting installer works using system libraries on most 'old current' current and newer distros. The caveat being that there are issues with some older png files in ancient OXP's.. I've posted a script that will fix that for all OXP's in a directory. Ultimately, moving to a newer libpng will mean old OXPs need a once-over to reduce log-spam on all systems.

The master source contains an older version of libpng, which I recall requires that the binary library needs to be included in the installer.

[mcarans]

I think that there would be little reason to retain espeak support for any platform once we transition to the new build (which should support both gcc and clang objc 2.2 on Windows and Linux with espeak-ng). espeak-ng works on Mac too. Do you think it would be still needed?

I think having multiple options available would make it easier to update things gradually.

hypothetical example
we have the following 8 targets :
sourcebuilds for windows , linux, intel macs, arm macs
binary builds for windows , intel macs, arm macs, linux flatpak

At some point in time we want to switch from libpng 20 to libpng 30 , but its only been tested on intel macs and windows sourcebuilds.
With the provider option we could enable libpng 30 for those 2 while we keep libpng 20 for the other 6 targets.

Multiple options will probably get confusing in makefiles so I'd suggest switching to cmake before introducing lots of configuration options. cmake can generate a Mac XCode project as well as being supported in CLion, VS Code etc. If we move to cmake I suggest a 2 phased approach - firstly just the build part (as I have done for Linux), later if it seems sensible, the packaging parts as cmake supports NSIS packaging on Windows although I'm not sure whether any Linux packaging types are supported.

[mcarans]

Current Ubuntu setups use libpng16, against which I build successfully on my fork. This means when I build on the oldest currently supported Ubuntu, the resulting installer works using system libraries on most 'old current' current and newer distros. The caveat being that there are issues with some older png files in ancient OXP's.. I've posted a script that will fix that for all OXP's in a directory. Ultimately, moving to a newer libpng will mean old OXPs need a once-over to reduce log-spam on all systems.

The master source contains an older version of libpng, which I recall requires that the binary library needs to be included in the installer.

Where are all OXPs hosted? If in multiple places, I think they should all be copied to GitHub. After being safely stored in GitHub, you could run your script against them.

[Lone_Wolf]

Current Ubuntu setups use libpng16, against which I build successfully on my fork.

As i mentioned in other threads that didn't work an archlinux , so there's more needed then just building with libpng16 installed.
Your fork changes a lot of things making it hard to figure out why something is or isn't working.

[Lone_Wolf]

A few general comments :

Once fleshed out I do intend to create MR/PR for these settings. If accepted similar ones can be added for any external dependency.

The methods used should work with oolite master and (future) stable versions, so cmake won't be used until it's supported by oolite.

Don't forget cmake started out as a system to make creating makefiles easier and still defaults to creating 'Unix makefiles' .

[Lone_Wolf]

The modern build uses settings that are very similar to (at the very least) a big part of what I wanted to achieve, so I'm no longer pursuing this.

Code: Select all

ifeq ($(modern),yes)


        SPEECH_LIBRARY_NAME          = espeak-ng


        OPENAL_LIBRARY_NAME          = openal


        LIBPNG_LIBRARY_NAME          = png


    else


        SPEECH_LIBRARY_NAME          = espeak


        OPENAL_LIBRARY_NAME          = openal32


        LIBPNG_LIBRARY_NAME          = png14


    endif