20,741
edits
Building using CMake: Difference between revisions
Jump to navigation
Jump to search
m
→Also see: moved from Post FlightGear 2020.2 LTS changes
m (→Linux / Unix: https://sourceforge.net/p/flightgear/mailman/message/37282835/) |
m (→Also see: moved from Post FlightGear 2020.2 LTS changes) |
||
| Line 1: | Line 1: | ||
{{Main article|Building Flightgear}} | {{Main article|Building Flightgear}} | ||
== | |||
== Current status == | |||
{{See also|Superbuild}} | |||
'''06/2020''': | |||
James has pushed some configuration changes to next (SG+FG) to raise various required versions of things. | |||
If you’re developing on ‘something fairly recent’, you shouldn’t see any difference except it would be a wise time to wipe your build dirs and re-CMake from clean. If you’re on a ‘somewhat older’ Linux, the baselines being Ubuntu 18.04 (their previous LTS) and CentOS 7 (which our Jenkins runs), you should also be fine except for GCC, where you will need a version supporting C++14: in practice this means GCC 5.x or higher. (Or use Clang…) For both of these distros there are officially supported ways to get newer GCCs (we’re actually using GCC 9 on Jenkins now..), so I don’t expect this to be a problem. | |||
As part of this we now require CMake 3.10<ref>https://sourceforge.net/p/flightgear/mailman/message/37094732/</ref>, Qt 5.9 and OSG 3.4.1, and James started removing various legacy pieces from next around this. There are plenty more cleanups that can be done based on this : especially on the CMake and C++ sides. Things like Boost -> Std stuff, Cmake targets-as-objects support (eg, target_compile_features can be used now). | |||
Windows and macOS should be unaffected BTW - because on those platforms you're always running something you downloaded which is fairly up to date. If you choose to go and download an ancient version of CMake or Qt, on either platform that’s your problem to fix - but you’ll get a configuration error at least. | |||
The idea of doing this /now/ is that the build deps won’t change again during the next two years, barring any surprises. | |||
None of this affects the release branches of course: they continue to work with OSG 3.2, GCC 4.x, Qt 5.4 and CMake 3.0. And you shouldn’t see any behavioural changes because of this either. | |||
Let’s see if reality corresponds to all the theory above :)<ref>https://sourceforge.net/p/flightgear/mailman/message/37041064/</ref> | |||
'''08/2020''': | |||
James pushed a large overhaul of the Cmake build files for FlightGear: | |||
* we now use modern Cmake style nearly everywhere, i.e targets-as-objects for an OOP-style build system | |||
* transitive dependencies are handled automatically (or at least, that’s the idea…), which simplifies things in many places (eg, audio library handling) | |||
* system vs built-in dependencies is handled vis ALIAS targets, so most other code doesn’t care. We link to a target which is an alias for either our built-in version or the system one (via an IMPORTED target) | |||
* we should have better isolation from system headers / versions of things. <ref>https://sourceforge.net/p/flightgear/mailman/message/37091728/</ref> | |||
== Build Environment & Dependencies == | == Build Environment & Dependencies == | ||