Link Time Optimizations

For discussion of ports to POSIX based systems, especially using GNUStep.

Moderators: another_commander, winston, Getafix

User avatar
mcarans
---- E L I T E ----
---- E L I T E ----
Posts: 732
Joined: Sun Jun 20, 2010 6:00 pm

Re: Link Time Optimizations

Post by mcarans »

another_commander wrote: Sun Dec 14, 2025 12:20 pm
All right, link time optimizations are now enabled for the deployment and test release installers for Linux and Windows*.

The snapshot installers have also been slightly re-configured. They now ship executables with debug information enabled and LTO disabled, so that debugging, if needed, can become easier. This makes the snapshot variant somewhat more useful, because until now the only difference between a test release and a snapshot was the watermark on the top right of the screen. If you want to concentrate on testing, you can use snapshot. If you want to just play with the best performance possible use deployment or test release.

* The modern build is required for LTO. Currently github builds Windows with the legacy environment and Linux with the modern configuration. As a result, only the Linux installers from github have LTO enabled, but you can still generate LTO builds for Windows if you build the installers yourself. This is expected to change soon, when we transition the github CI workflow to use the modern build configuration also for Windows.
I've integrated these changes into the modern_linux branch which produces appimage releases for Linux.
https://github.com/mcarans/oolite/actio ... 0217625848

It also has an additional GitHub Actions workflow that builds from source on Fedora and Arch for testing purposes (the build-all one uses Ubuntu).

I think the GitHub Actions workflows will need some rethinking because if we make a release (rather than a pre-release), we may not want the snapshot build in it. There are also some other parts of the build_all workflow that probably only need to run on the main Oolite repo's master branch and not forks or branches. Another question is whether it's desirable to produce a pre-release on every commit to master or if it should be created in the GH UI's release.

The PR I will make will not address refactoring the GH Action workflow to avoid confusion over what exactly has been added or changed for the Linux appimage.
Post Reply