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.

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)

#HDF5 jest super. W skrócie:

1. Oryginalnie, projekt używał systemu budowania autotools. Instalował binarkę h5cc, która — obok bycia nakładką na kompilator — miała dodatkowe opcje do uzyskiwania informacji o instalacji HDF5.
2. Później dodano alternatywny system budowania #CMake. W ramach tego systemu budowania instalowana jest uproszczona binarka h5cc, bez tych dodatkowych funkcji.
3. Każdy, kto próbował budować przez CMake, szybko odkrywał, że ta nowa binarka psuje większość paczek używających HDF5, więc wracano do autotools i zgłoszono problem do HDF5.
4. Autorzy zamknęli zgłoszenie, stwierdzając (tłum. moje): "Zmiany w h5cc przy użyciu CMake zostały udokumentowane w Release.txt, kiedy ich dokonano - kopia archiwalna powinna być dostępna w plikach z historią."
5. Autorzy ogłosili zamiar usunięcia wsparcia autotools.

Co stawia nas w następującej sytuacji:

1. Praktycznie wszyscy (przynajmniej #Arch, #Conda-forge, #Debian, #Fedora, #Gentoo) używa autotools, bo budowanie przy pomocy CMake psuje zbyt wiele.
2. Oryginalnie uznano to za problem w HDF5, więc nie zgłaszano problemu innym paczkom. Podejrzewam, że wiele dystrybucji nawet nie wie, że HDF5 odrzuciło zgłoszenie.
3. Paczki nadal są "zepsute", i zgaduję, że ich autorzy nawet nie wiedzą o problemie, bo — cóż, jak wspominałem — praktycznie wszystkie dystrybucje nadal używają autotools, a przy testowaniu budowania CMake nikt nie zgłaszał problemów do innych paczek.
4. Nawet nie mam pewności, czy ten problem da się "dobrze" naprawić. Nie znam tej paczki, ale wygląda to, jakby funkcjonalność usunięto bez alternatywy, i tym samym ludzie mogą co najwyżej samemu zacząć używać CMake (wzdych) — tym samym oczywiście psując swoje paczki na wszystkich dystrybucjach, które budują HDF5 przez autotools, o ile nie dodadzą dodatkowo kodu dla wsparcia tego drugiego wariantu.
5. Wszystko wskazuje na to, że HDF5 jest biblioteką, której autorów nie obchodzą ich własni użytkownicy.

https://github.com/HDFGroup/hdf5/issues/1814

#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.

https://github.com/HDFGroup/hdf5/issues/1814

I did it again: create a project builder, this time bash-only.

https://codeberg.org/harald/bashbuilder

This is my fourth.

This YT short summarizes changes needed to have a Qt Quick app work with both Qt 5 and Qt 6. It primarily focuses on required changes to #QML and #CMake files, but it also mentions other aspects of porting C++ and shaders: https://www.youtube.com/shorts/zQ5hNgwuC4g #QtDev #Cpp
https://www.youtube.com/shorts/zQ5hNgwuC4g

C++ with #RustLang Bindings: Mixing with #CMake

https://youtube.com/watch?v=EcbmDXA4Inc

I updated #mbedTLS and #curl in #DOjS. This one took a lot longer than I expected because curl dropped Makefile.mk builds and I had to switch to #CMake or #autconf.
I went with CMake, but had to work around some weird problems.

#MSDOS and #Linux build are already green again, I'll tackle #win32 later...

Jak działają paczki z wieloma systemami budowania do wyboru (albo oficjalnie wspieranymi, albo przez użytkowników):

1. Paczka ma podstawowy system budowania, którym nie jest #CMake.
2. Ktoś dodaje wsparcie budowania przez CMake.
3. Przypadkowe inne paczki zaczynają używać plików eksportów, które są instalowane tylko przez CMake.
4. Dystrybucje zaczynają korzystać z budowania przez CMake.
5. W kolejnym wydaniu, budowanie przez CMake zostaje popsute (znowu).
6. Nikt nie wie, czy możemy przełączyć z powrotem na działający system budowania, bo nikt nie ma pojęcia, jak wiele paczek wymaga plików eksportów od CMake.

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.

Every time I need to touch #cmake I feel an intense urge to become a professional basket weaver.

I think it would be 900x less painful if it didn't use a bizarre bespoke configuration language and picked something established like lua.

OK, I'm trying to build some mixed C++, ObjC and Swift code with CMake (CLion).

Since the Xcode generator doesn’t seem to work with Swift anymore, I switched over to Ninja, and now all ObjC files are built without ARC.

How do I tell CMake with Ninja to build ObjC(++) files with ARC, but not Swift files??

I find it weird that there are plenty of hidden features in #cmake which are not documented. I found out the other day that `CMAKE_STRIP` is a thing, and it helped me finalize my #osx cross-packaging. I found it because I was missing this feature and was about to post an issue, but then searched through their code base and accidentally stumbled upon it. Have yet to find anything documenting it.

I've just released the #Python wheels for today's release of #CMake 4.0! https://pypi.org/project/cmake/ Remember to set your CMake minimum version to at least 3.5 (3.15 or better preferred) and set a maximum version too (newer CMake follows the policies of the maximum version) #release

Boost Your CMake Development with Copilot Custom Instructions. buff.ly/Fl5FlsB #cpp #ai #cmake #visualstudio #copilot #githubcopilot #productivity

Boost Your CMake Development w...

Boost Your CMake Development with Copilot Custom Instructions.

https://devblogs.microsoft.com/cppblog/boost-your-cmake-development-with-copilot-custom-instructions/

iRODS Development Update: March 2025

https://irods.org/2025/03/irods-development-update-march-2025/