[Flightgear-devel] Cmake clean-up

[James T. <ja...@fl...>]

I’ve just 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. Maybe.

- I’ve tested with and without GDAL, and with SYSTEM_ versions of various libraries (FLITE, SPEEX, etc)

There’s probably some combinations I’ve missed, and some further improvements to make. But the ‘nothing changed’ time to run ninja is now < 0.2 seconds on my machine, not bad at all. (I was able to make fgrcc run ‘on demand’ which helped quite a bit). Visua;l Studio ‘hit build and run’ is also pretty fast (and that’s inside a virtual machine), some further improvements possible there.

So, please test, and report any non-working configurations.

There’s some further improvements I will make, and one that need some thought: ENABLE_GDAL leaks GDAL headers into Simgear’s public headers, which seems … unfortunate. It means in a GDAL build, all of SimGear and all of Flightgear gets compiled with the GDAL headers. Can someone who knows what the GDAL support is for, explain if this is really required? Since I suspect some forward decelerations and the like could improve this, and we could make GDAL a private dependency.

Kind regards,
James