Thank you: Dynamic libraries

I’ve worked at a few well-known organizations where the decision not to use CMake could ultimately be anchored on what it took to ask CMake to do a most trivial of build-system things: build “myexe” in ${build_dir} and copy across the dependent shared-objects.

In the last half decade, that’s been entirely unfair - it was still not easy to get working, and it’s still got a lot of platform-specific stuff even in 3.22, but it was a lot easier.

With 3.21 you’re really closing in on this.

I wanted to take the time to say Thank you for this particular effort, because it’s likely that the majority of current cmake users either don’t need it, avoid dynamic resources to avoid it, or they’ve built their own suite of tools to work around the missing facilities.

My current responsibilities put me into the second 2 categories: We have nearly 400 cmake targets, 580 cmake files, (not inc 3rd party), we have over 48,000 lines of 1st party cmake code.

We’ve put hundreds of manhours into working around converting individual dependencies rather than have to try and get cmake to do the right things, and we’ve twice actually begun a migration to a different build system because the CTO just couldn’t accept how difficult it was in CMake (3.18 and earlier).

Today I was able to ditch nearly 300 lines of 2.x-3.x hybridized old cmake stuff with a few lines of target() rules and an IMPORTED library definition. It doesn’t quite get us the whole way - we still need dozens of lines of calls to post-build-step functions with lots of arguments and global variables and includes, to get the dynamics copied into the build directory and/or ctest directory, but we’re able to (mostly) leverage “cmake --install” to address ci/cd problems that have been a headache for years.

Thank you, and keep up the excellent work. I really think that with this thankless undertaking you’re lifting the giant column atop which people found a straw that broke their camel’s back.

5 Likes