Modern build transition ready for testing

[another_commander]

The modern_build_transition branch is now ready for final testing on Windows.

It should now be possible to build Oolite using a common codebase and any of the three available development environments: legacy, mingw64-msvcrt and clang-ucrt.

Build configuration is decided automatically based on the gcc version. If gcc 4.7.1 is found then the build is configured for legacy and if gcc version is anything other than that the build is configured as modern.

Please test using any environment you prefer. If you build modern, then be aware that the build system expects a setup equal to what mcarans' install scripts generate. You should follow the instructions in his oolite_windows_installer branch of his Oolite cloned repository to get that environment up and running. In the future I could probably upload a pre-configured modern dev environment similar to what we have for legacy, where everything is ready to just copy over and start using right away.

Note that the Linux build is not affected by all this and still uses espeak instead of espeak-ng. The support for espeak-ng on Linux will have to be added and then the makefiles can easily be switched to that.

If you find any issues, please let us know. If all seems good, then the next step is to make a PR and officially get into the transition phase to the new build system.

[mcarans]

The modern_build_transition branch is now ready for final testing on Windows.

It should now be possible to build Oolite using a common codebase and any of the three available development environments: legacy, mingw64-msvcrt and clang-ucrt.

Build configuration is decided automatically based on the gcc version. If gcc 4.7.1 is found then the build is configured for legacy and if gcc version is anything other than that the build is configured as modern.

Please test using any environment you prefer. If you build modern, then be aware that the build system expects a setup equal to what mcarans' install scripts generate. You should follow the instructions in his oolite_windows_installer branch of his Oolite cloned repository to get that environment up and running. In the future I could probably upload a pre-configured modern dev environment similar to what we have for legacy, where everything is ready to just copy over and start using right away.

Note that the Linux build is not affected by all this and still uses espeak instead of espeak-ng. The support for espeak-ng on Linux will have to be added and then the makefiles can easily be switched to that.

If you find any issues, please let us know. If all seems good, then the next step is to make a PR and officially get into the transition phase to the new build system.

This worked for me on legacy and modern on Windows. Linux needs the following in GNUmakefile:

Code: Select all

    ifeq ($(modern),yes)
        ADDITIONAL_CFLAGS        += -DOOLITE_MODERN_BUILD=1
        ADDITIONAL_OBJCFLAGS     += -DOOLITE_MODERN_BUILD=1
    endif

It can be put below:

Code: Select all

    ADDITIONAL_CFLAGS            = -Wall -DLINUX -DNEED_STRLCPY `sdl-config --cflags` `nspr-config --cflags`

It would be a bit nicer to set OOLITE_MODERN_BUILD once rather than in each ifdef branch since it affects both builds.

These lines can be removed. I tested on Windows and Linux:

Code: Select all

# Add flag if building with GNUStep and Clang
ifneq '' '$(GNUSTEP_HOST_OS)'
    ifneq '' '$(findstring clang++,$(CXX))'
        ADDITIONAL_OBJCFLAGS += -fobjc-runtime=gnustep-2.2
    endif
endif

I only tested the modern build on Linux as it is not as easy to switch builds as on Windows, but anyway the legacy build is somewhat broken on Linux right now requiring the changes MrFlibble has in his fork. The only thing missing for the modern build on Linux is copying over espeak-ng-data something I'll look into later.

I am happy for your changes to be merged.

[another_commander]

I have applied the proposed changes and checked that the Windows build works on my side for all configurations. Linux CI on github failed due to safeguards in the code though. Here is the error message received from the CI runner:

Code: Select all

In file included from src/Core/Debug/OODebugStandards.h:29,
                 from src/Core/Debug/OODebugStandards.m:30:
src/Core/OOCocoa.h:56:18: error: #error Oolite modern build cannot be generated using GNUstep earlier than 1.31.
   56 |                 #error Oolite modern build cannot be generated using GNUstep earlier than 1.31.
      |                  ^~~~~
make[5]: *** [/usr/share/GNUstep/Makefiles/rules.make:521: obj.spk/oolite.obj/OODebugStandards.m.o] Error 1
make[4]: *** [/usr/share/GNUstep/Makefiles/Instance/objc.make:64: internal-objc_program-all_] Error 2
make[3]: *** [/usr/share/GNUstep/Makefiles/Master/rules.make:297: oolite.all.objc-program.variables] Error 2
make[2]: *** [/usr/share/GNUstep/Makefiles/Master/objc.make:36: internal-all] Error 2
make[2]: Leaving directory '/home/runner/work/oolite/oolite/oolite'
make[1]: *** [Makefile:133: deps-release-deployment] Error 2
make[1]: Leaving directory '/home/runner/work/oolite/oolite/oolite'
+ make_rc=2
+ '[' 2 -ne 0 ']'
+ exit 2
make: *** [Makefile:206: pkg-posix] Error 2
Error: Process completed with exit code 2.

I think the Linux CI build should be switched to use gnustep-base 1.31. I am not sure how to do that though. Alternatively I guess I could switch the safeguards in the code to check for whatever gnustep the Linux machines on github are loaded with. Merging of the changes will have to wait a bit until this is sorted out.

[another_commander]

OK, I lowered the gnustep-base version requirement to 1.28.0 for a modern build and this allowed Linux to pass CI. So I guess PR is coming up real soon now.

Edit: PR #530 issued and ready to merge.

[mcarans]

OK, I lowered the gnustep-base version requirement to 1.28.0 for a modern build and this allowed Linux to pass CI. So I guess PR is coming up real soon now.

Edit: PR #530 issued and ready to merge.

Great! I can look into the CI later. I think that something similar to the GH Action workflow in https://github.com/mcarans/oolite_windows_installer/ can be used for the Windows modern build CI as it creates an environment and builds installers similar to the Windows legacy CI. I need to make an equivalent for the Linux modern build.

[another_commander]

As of today, the Windows pre-release binaries are created using mcarans' new development environment and are generated using the Clang compiler with the UCRT64 runtime. They are as modern as it gets.

Please feel free to download, test drive them and let us know if anything seems off.

When I downloaded the test-release binary, Defender immediately jumped in and deleted it thinking it was malware. I have already filed a report with Microsoft and hopefully this will be fixed soon. In the meantime be assured that it is safe to keep the download and run it.

[Mauiby de Fug]

Incredibly exciting! Well done everyone!

I've noticed that the snapshot version no longer has the full version revision displayed in the watermark.

[mcarans]

Incredibly exciting! Well done everyone!

I've noticed that the snapshot version no longer has the full version revision displayed in the watermark.

Thanks for testing. I will look into that.

[mcarans]

As of today, the Windows pre-release binaries are created using mcarans' new development environment and are generated using the Clang compiler with the UCRT64 runtime. They are as modern as it gets.

Please feel free to download, test drive them and let us know if anything seems off.

When I downloaded the test-release binary, Defender immediately jumped in and deleted it thinking it was malware. I have already filed a report with Microsoft and hopefully this will be fixed soon. In the meantime be assured that it is safe to keep the download and run it.

One thing I have yet to do is to switch from the JS dll to static linking. I think it could work similarly to how it works now with dlls ie. that modern will look in /ucrt64/lib so I will need to update the Spidermonkey MSYS2 package. Do you want to switch legacy to use static as well? If so, then please can you upload the legacy library you already built and tested to https://github.com/OoliteProject/oolite ... ECMAv5/lib.

[another_commander]

The static legacy build libjs together with the required nspr4 import lib have been uploaded to Windows deps.

[another_commander]

Thanks for testing. I will look into that.

There is also one more thing: the PDFs accompanying the game in the new installers are the ones marked as "Outdated" in the Doc folder, instead of the automatically updated ones.

If it's too much of a hassle to fix, I'd rather update the PDFs in the Doc folder to be the most current ones and get them to refer to version 1.92 of the game. These documents are supposed to be changed once every two or three years prior to release anyway and 1.92 should not be too far away now.

[mcarans]

Thanks for testing. I will look into that.

There is also one more thing: the PDFs accompanying the game in the new installers are the ones marked as "Outdated" in the Doc folder, instead of the automatically updated ones.

If it's too much of a hassle to fix, I'd rather update the PDFs in the Doc folder to be the most current ones and get them to refer to version 1.92 of the game. These documents are supposed to be changed once every two or three years prior to release anyway and 1.92 should not be too far away now.

I guess I must have missed something in the GH Actions workflow which is quite complicated. Presumably it generates the updated PDF somewhere and I'll need to copy it into the build/nsis folder. I'll see if I can work out what I've missed.

[mcarans]

I tried to see if putting the MingW trampoline file in a clean build of the JavaScript fixes it, but can't get anywhere with it. I'm now updating the existing Spidermonkey packages to output the static lib (as well the dll).

If we're going to make major updates to the documentation that comes with the game, then I think it's time to bite the bullet and look at readthedocs with mkdocs. Docs in files don't really suit AppImage (which is just a single file) or Flatpak (which installs to a not very obvious location), so the docs need to be easily accessible on the internet. It'll also make them much easier to update - just edit some markdown.

I can export the odt files used to make the existing pdfs to markdown in LibreOffice. The Doxygen generation can all be done in readthedocs too. That will greatly simplify the build workflow as there won't be a need for a pre build step to generate documentation or a post build one to deploy a website. All of that will be in a separate readthedocs setup.

[another_commander]

If we're going to make major updates to the documentation that comes with the game, then I think it's time to bite the bullet and look at readthedocs with mkdocs. Docs in files don't really suit AppImage (which is just a single file) or Flatpak (which installs to a not very obvious location), so the docs need to be easily accessible on the internet. It'll also make them much easier to update - just edit some markdown.

I can export the odt files used to make the existing pdfs to markdown in LibreOffice. The Doxygen generation can all be done in readthedocs too. That will greatly simplify the build workflow as there won't be a need for a pre build step to generate documentation or a post build one to deploy a website. All of that will be in a separate readthedocs setup.

Agreed. The docs inside the files distributed with installers would be a good idea IF people cared to look at them. Just going by the number of people who still think that Oolite has no yaw controls, I can tell that no one gives a sh!t about the docs. So, if we can migrate them out to an external source, maybe that makes it easier for everyone.

In addition to that, docs in files don't suit MSIX distributions either. MSIX is very similar to flatpak in how it sets up the container inside which the application runs and documentation files would just get lost and almost become unreachable as a result.

[mcarans]

Agreed. The docs inside the files distributed with installers would be a good idea IF people cared to look at them. Just going by the number of people who still think that Oolite has no yaw controls, I can tell that no one gives a sh!t about the docs. So, if we can migrate them out to an external source, maybe that makes it easier for everyone.

In addition to that, docs in files don't suit MSIX distributions either. MSIX is very similar to flatpak in how it sets up the container inside which the application runs and documentation files would just get lost and almost become unreachable as a result.

Great, I'll look into that.

https://github.com/OoliteProject/oolite ... /tag/0.0.8 contains the Spidermonkey package that installs libjs.a into /ucrt64/lib. It worked for me with:

Code: Select all

JS_IMPORT_LIBRARY        = js
...
ADDITIONAL_OBJC_LIBS         = -lglu32 -lopengl32 -l$(OPENAL_LIBRARY_NAME).dll -l$(LIBPNG_LIBRARY_NAME).dll -lmingw32 -lSDLmain -lSDL -lvorbisfile.dll -lvorbis.dll -lz -lgnustep-base -l$(JS_IMPORT_LIBRARY) -lnspr4 -lshlwapi -ldwmapi -lwinmm -mwindows