4 ms·

Canadian crosses may be a niche case but they're my bread and butter as a host tool maintainer for embedded development systems. CMake is almost at par with th

by bregma 3y ago

Canadian crosses may be a niche case but they're my bread and butter as a host tool maintainer for embedded development systems. CMake is almost at par with the autotools in terms of functional support but much more difficult to analyze when things go wrong. I can easily instrument a generated configure script or makefile to analyze what's happening and then trace it back to its original input to the autotools to make adjustments. The same thing with a CMake build often requires not only analyzing generated makefiles but CMake sources distributed with my project and across my build system where they may be installed by various packages and sometimes even the C++ code of the tool itself. I will work with CMake if I have to and embrace autotools where I can. Anything that depends on pkg-config is just plain broken for me. Sure, I could modify each and every project to use customized configurations set through writing wrapper scripts and modifying system tools and setting special environment variables to make it work for some simple cases, but that's not scalable in CI systems where I have no root access and it just doesn't work at all for any cross-build situations where build-host tools are used to generate target files. Tools are supposed to make it easier, not impossible. It's great if you can focus on one example that works for you. It's not so great when you have to deal with dozens of different examples, all different, most of which don't work and require all kinds of manual intervention just to solve problems that have already been solved decades ago but for Chesterton's fence.

bonzini 3y ago
I agree that Canadian crosses are necessary, but they affect a really small minority of programs and they are either not using Autotools (LLVM/clang, QEMU) or not going to migrate away from it (GCC/binutils/gdb). All I wanted to say is that there are also cases that go beyond the Canadian cross and IMO it was not a mistake for Meson to focus on good support for build vs host and leave the target aside. With respect to pkg-config, I don't know. I still find it a better tradeoff in terms of both ease of use and discoverability. I am not 100% sure it's a problem of the tool. In my experience doing cross compilation it's never gotten in the way, I can imagine it may introduce some headaches for those that work on the meta-buildsystem (e.g. buildroot or yocto) but overall it's hard to prefer either config-script-of-the-day (which almost always has exactly the same problem just multiplied by N) or cmake-macro-of-the-day. Agreed 100% on the relative advantages/disadvantages of CMake vs autotools. As a developer Meson however is night and day when compared to both.

by bregma 3y ago

bonzini 3y ago

I agree that Canadian crosses are necessary, but they affect a really small minority of programs and they are either not using Autotools (LLVM/clang, QEMU) or not going to migrate away from it (GCC/binutils/gdb). All I wanted to say is that there are also cases that go beyond the Canadian cross and IMO it was not a mistake for Meson to focus on good support for build vs host and leave the target aside. With respect to pkg-config, I don't know. I still find it a better tradeoff in terms of both ease of use and discoverability. I am not 100% sure it's a problem of the tool. In my experience doing cross compilation it's never gotten in the way, I can imagine it may introduce some headaches for those that work on the meta-buildsystem (e.g. buildroot or yocto) but overall it's hard to prefer either config-script-of-the-day (which almost always has exactly the same problem just multiplied by N) or cmake-macro-of-the-day. Agreed 100% on the relative advantages/disadvantages of CMake vs autotools. As a developer Meson however is night and day when compared to both.