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