2 ms·

The problem with pkg-config is that it's really really broken for cross builds. Meson depends on pkg-config so it's inappropriate for cross builds. It doesn't e

by bregma 3y ago

The problem with pkg-config is that it's really really broken for cross builds. Meson depends on pkg-config so it's inappropriate for cross builds. It doesn't even pretend to support Canadian crosses. CMake works for cross builds, as long as the company has ported their proprietary CMake program to build for your target or you supply your own hand-rolled tools file and trick it into using that. Autotools works for cross building right out of the box almost every time.

bonzini 3y ago
This does not match my experience, pkg-config can be used for cross compilation. In Autoconf terms it's a "tool", not a "program". If you're cross compiling to Arm from x86, you can either create a separate arm-linux-gnueabi-pkg-config installation that has a different search path for .pc files, or you can even just create a wrapper script that passes the right search path override to the system pkg-config. Either way, it's not a problem to cross compile with Meson, and most cross compilation environments are ready for it and have been for a decade or more. QEMU builds many cross compilation CI jobs and they handle Meson/pkg-config just fine. Where pkg-config goes almost irrimediably wrong, it's for multilib compilations (such as using -m32 to compile for 32-bit x86 on a 64-bit host). In that case there's no alternative to passing overrides in the environment. Which is pretty bad, not entirely broken I guess but pretty close. As to lack of support for Canadian crosses, that's a very niche case (and I say that as a former build system maintainer for GCC/binutils) and even then no build system is perfect. Looking again at QEMU, we need to build testcases for a dozen different targets, and Autoconf would only support one. In QEMU we use Meson for the more complex and configurable part of the build, and wrap it with a handwritten and decently readable configure/Makefile pair to handle target builds and orchestrate everything. We can do enough in Mason that the configure script's tasks are very specialized and would benefit very little from using a build-specific DSL like Autoconf's m4 dialect or CMake. For our use case it hits a sweet spot in terms of maintainability and is even more flexible than Autotools.
- 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

This does not match my experience, pkg-config can be used for cross compilation. In Autoconf terms it's a "tool", not a "program". If you're cross compiling to Arm from x86, you can either create a separate arm-linux-gnueabi-pkg-config installation that has a different search path for .pc files, or you can even just create a wrapper script that passes the right search path override to the system pkg-config. Either way, it's not a problem to cross compile with Meson, and most cross compilation environments are ready for it and have been for a decade or more. QEMU builds many cross compilation CI jobs and they handle Meson/pkg-config just fine. Where pkg-config goes almost irrimediably wrong, it's for multilib compilations (such as using -m32 to compile for 32-bit x86 on a 64-bit host). In that case there's no alternative to passing overrides in the environment. Which is pretty bad, not entirely broken I guess but pretty close. As to lack of support for Canadian crosses, that's a very niche case (and I say that as a former build system maintainer for GCC/binutils) and even then no build system is perfect. Looking again at QEMU, we need to build testcases for a dozen different targets, and Autoconf would only support one. In QEMU we use Meson for the more complex and configurable part of the build, and wrap it with a handwritten and decently readable configure/Makefile pair to handle target builds and orchestrate everything. We can do enough in Mason that the configure script's tasks are very specialized and would benefit very little from using a build-specific DSL like Autoconf's m4 dialect or CMake. For our use case it hits a sweet spot in terms of maintainability and is even more flexible than Autotools.

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.