The best part of #Meson is `meson.options` file.
So much better than #CMake and `option()` and `set(... CACHE ...)`, and `find_package()`, and some other functions and macros, split across a hundred `CMakeLists.txt` files, a dozen `*.cmake` files and possibly some other files you don't expect. And then some random variables that aren't meant to be modified by user but you need to set them anyway, because the whole thing is so broken.
Improvements to my bash-only build system:
* Adds (environment) variables as dependencies/targets on par with files and directories.
* Changes call direction from bashbuilder->buildscript to the reverse. Now bashbuilder is "merely" a library, instead of requiring to be 'main'.
* Adds generated file lists as dependencies/targets.
https://codeberg.org/harald/bashbuilder
#bashbuilder
#buildsystem
#softwaredevelopment
#programming
#make
#gradle
#ant
#blt
#cmake
I'm trying to use two GitHub library projects as dependencies.
One of them doesn't define a #CMake project, so I was pulling it in as a git submodule (blah).
The second defines a CMake project, but also install goop, so the library was barfing into my application's install tree (blah).
I'm at the point of forking them both to control what they do, and then using FetchContent instead of submodules to pull them into my build tree (blah).
I like #CMake but I don't love it. It's too hard to thread the needle for different use cases of a library, for example:
No install directives? Now nobody can use your stuff, except by including it in their own build trees.
Defined install directives but are not shipping a package anywhere? Now nobody can use your stuff, unless they want to accidentally redeploy it into their own install trees.
Also the install stuff is super goopy and unintuitive, with tons of conflicting examples.
I don't understand why, but support for the "Ninja Multi-Config" generator keeps coming and going from various #CMake releases for different environments.
I should probably just try to ditch it anyway, as I'm not really taking advantage of it anyway. The whole "defer thinking about build flavor until the build stage" concept in CMake feels really tacked-on, resulting in an ugly mess.
To try and make the binary work outside the container I've been trying to force #CMake to statically link dependencies by default, but there doesn't seem to be a blanket way to set that. Unless I'm mistaken I need to set it one library at a time.
(2/2)
Trying to use a #DevContainer to work on an existing open-source project that uses #CMake . The devcontainer works great for the build, I can set up the various dependencies to only be installed in the container, keeping the host nice and clean.
It's not trivial to _run_ the application after it's built however. It's a GUI app, so running from inside the container doesn't seem to work (cannot connect to display). Running outside doesn't due to the missing shared libs.
(1/N)
I wanted to say that “of course, #openSUSE uses #CMake, because we do The Right Thing™”, but then I had a look at our SPEC https://build.opensuse.org/projects/openSUSE:Factory/packages/hdf5/files/hdf5.spec?expand=1 … yes, we use CMake, but that’s A LOT of hand-waving around it to make it work!
#HDF5 is doing great. So basically:
1. Originally, upstream used autotools. The build system installed a h5cc wrapper which — besides being a compiler wrapper — had a few config-tool style options.
2. Then, upstream added #CMake build system as an alternative. It installed a different h5cc wrapper that did not have the config-tool style options anymore.
3. Downstreams that tried CMake quickly discovered that the new wrapper broke a lot of packages, so they reverted to autotools and reported a bug.
4. Upstream closed the bug, handwaving it as "CMake h5cc changes have been noted in the Release.txt at the time of change - archived copy should exist in the history files."
5. Upstream announced the plans to remove autotools support.
So, to summarize the current situation:
1. Pretty much everyone (at least #Arch, #Conda-forge, #Debian, #Fedora, #Gentoo) is building using autotools, because CMake builds cause too much breakage.
2. Downstreams originally judged this to be a HDF5 issue, so they didn't report bugs to affected packages. Not sure if they're even aware that HDF5 upstream rejected the report.
3. All packages remain "broken", and I'm guessing their authors may not even be aware of the problem, because, well, as I pointed out, everyone is still using autotools, and nobody reported the issues during initial CMake testing.
4. I'm not even sure if there is a good "fix" here. I honestly don't know the package, but it really sounds like the config-tool was removed with no replacement, so the only way forward might be for people to switch over to CMake (sigh) — which would of course break the packages almost everywhere, unless people also add fallbacks for compatibility with autotools builds.
5. The upstream's attitude suggests that HDF5 is pretty much a project unto itself, and doesn't care about its actual users.
How packages with multiple build systems to choose from (either officially supported, or user-maintained) work:
1. The package has a primary non-CMake build system.
2. A #CMake build system is added.
3. Random reverse dependencies start depending on CMake exports from given package.
4. Distributions start switching over to CMake.
5. CMake turns out to be broken (again) in the next release.
6. You don't know if you can switch back, because you have no clue if some of the reverse dependencies don't require CMake exports.
Few days ago, #CMake 4.0 came out. I wonder if it is easy to use now..
#coding #programming #cpp
Great news! We just got some packaging work done that's going into the rebase branch. It is now possible to build #AppImages and installers again!
On top of that, SHA256 hashes are now automatically generated, and we now build our installer with #CPack using a custom #CMake script, so all packaging is the same process. When we bring back nightly builds, this will be a nice way to verify your download. Plus, it will save us a few steps in packaging official binaries 
Packaging a C++ library with CMake when multi-configuration generator is used is so frustrating, if not borderline impossible...
The closest I've got so far is to build two archives (debug and release) and somehow merge them into one...
Mini-rant ahead:
I'm delving into #cmake to try to make it build a compile_commands.json file to work with #retrocomputing C header files, specifically the #Psion SIBO C SDK (from the early 90s).
I don't actually want cmake to do anything but tell clangd what to do, so that I've got a working language server in NeoVim.
I don't need it to build any Makefiles, I don't need it to tell a compiler what to do. I just want clangd to treat my old 16-bit real mode code correctly, and that the header files are in ~/dosbox/sibo-c/SIBOSDK/include/.
Note that I can't point it at the compiler, because the compiler (TopSpeed) runs in DOSBox. There is no modern compiler that will work.
So... Do I have to fake it somehow? For example, do I have to tell cmake that it's actually using a different compiler (e.g. #Watcom) to make it behave correctly? And if I do, will that matter to clangd?
New on the blog: Discover how we used #Nix and #NixOS to package a hybrid #CMake project with #Rust dependencies using Corrosion! Learn how to tackle dependency management challenges and build #reproducible systems. 
Read here: https://cyberus-technology.de/en/articles/nix-cmake-corrosion #DevOps #FOSS
@nyurik and I added the ability to use #Rust for #MapLibre Native development. We use two build tools #CMake and #Bazel, which required some work on the build setup, but all in all the integration was pretty smooth. Even the debugger works fine without any additional setup. We're using https://cxx.rs for safe interoperability.
![Terminal screenshot, output of nixos-rebuild -L -v showing that cmake is currently built, but the build logs with their progress percentage in square brackets like [54%] and the following colorful 'Building CXX object ...' looks an awful lot like a cmake output itself.](https://cdn.fosstodon.org/media_attachments/files/113/839/196/810/021/425/original/c1ee87a497d803f9.png "Terminal screenshot, output of nixos-rebuild -L -v showing that cmake is currently built, but the build logs with their progress percentage in square brackets like [54%] and the following colorful 'Building CXX object ...' looks an awful lot like a cmake output itself.")
