5 ms·

I recently had to build a couple of external packages that had switched to meson for internal deployment - I wasn't left _terribly_ impressed. Almost all the de

I recently had to build a couple of external packages that had switched to meson for internal deployment - I wasn't left _terribly_ impressed. Almost all the dependencies either required pkg-config support (which lots of the standard builds of said packages didn't deploy), or leaned heavily on CMake to actually resolve the dependencies (except for the one package with a custom meson dependency resolver - which couldn't use either and needed to be hacked). Am I thinking of it wrong, and using it as a "layer" above CMake to do the heavy dependency lifting is an intended part of Meson? Cmake has _huge_ support and mindshare in terms of third party packages and dependencies, even if it is somewhat difficult to learn "good" methods of writing CMakeLists. I feel like spending the effort to learn a complete new build configuration metalanguage - and having to rewrite dependency discovery/builds, would be better spent on something like Bazel and it's mass-distributed compile capabilities, rather than something that looks just like cmake but with a new and unique language that to general approximation nobody else uses. This is admittedly a rather uncharitable and possibly unfair way of looking at it - and I don't begrudge anyone trying to find a way of writing builds that fits better with them. Perhaps It's just a personal bias and I'm just getting to the age where learning a tool thoroughly and writing stuff that other people have a higher chance of experience in becomes more important than chasing... whatever it is that people value in this. (Or perhaps I have been too burnt by insanely complex badly implemented fragile SCons systems and not enough bad CMake systems).

oriolid 5y ago
Just out of curiosity, which packages do use Meson as wrapper over CMake? Sounds like total misuse but I'm interested in how it's done.
- misnome 5y ago
  Not specifically a wrapper, but it's built into Meson: https://mesonbuild.com/Dependencies.html#dependency-detection-method https://mesonbuild.com/Dependencies.html#dependency-detectio... > For dependencies without specific detection logic, the dependency method order for auto is: pkg-config cmake
  - oriolid 5y ago
    Thanks. It's a fairly new feature, I didn't know about it. It's certainly annoying that distros don't have good pkg-config support, it would be so much nicer than writing detection logic or reusing CMake.
    - mathstuf 5y ago
      (FD: CMake developer) In my experience, it's that pkg-config assumes that everything needed to consume a library can be communicated via flags spelled as GCC spells them. There are many compilers which don't speak GCC on the command line. Some are popular (Intel and MSVC come to mind).
      - oriolid 5y ago
        Good point. I have always been thinking that the practical way with MSVC is to just embed everything into the project because everything else is too much work. Perhaps it's time to change that now.
nolta 5y ago
Yeah, i had the same reaction. For example, meson couldn't find pybind11 until i added `pybind11-config --cmakedir` to CMAKE_PREFIX_PATH.
ho_schi 5y ago
Why this packages doesn't provide pkg-config after so many years? On Linux literally every library comes with pkg-config readily available and the same is possible on Windows (MSYS2) and MacOS (that beer thing).
- misnome 5y ago
  Maybe if you are installing from a distro-provided central repository like debian and only using system package-managed sources, and nothing exotic. On a cursory check, the conda environment that we build off has 250 packages in, and only 60 .pc files. And to be fair, only 50 entries in lib/cmake, but a lot of the CMake dependency resolution is built into CMake (and does pkg-config support separated components as part of a package, like e.g. Boost which apparently has a 14-year-old unresolved ticket to add pkg-config support). All our "build from source" HDF5 installs don't have this either. Nor does debian have .pc files for their distribution of one of our key libraries (which we don't use via debian, but still....). This seems a very, very long way from "literally every library comes with pkg-config".
dundarious 5y ago
I have no issue with projects like meson using FindFoo.cmake packages in principle. The problem with CMake is that most such packages aren’t implemented via just an export, as in https://cmake.org/cmake/help/latest/guide/importing-exporting/index.html#exporting-targets https://cmake.org/cmake/help/latest/guide/importing-exportin... Such packages and exports are really just simple config files that I think can be safely treated as declarative — they become a perhaps uglier, but portable alternative to pkg-config. As such, having meson read them would be a smart move, and would be quite simple. Unfortunately, CMake doesn’t have a culture of creating/installing/using exports IME, and so you end up with enormous, complicated Find packages that do fancy bespoke dynamic search logic. THAT isn’t something I’d like a project like meson to lean on, but only because the goal should be to remove the need for such things, not depend on them further. CMake doesn’t help matters by making exports fiddly.
gravypod 5y ago
I really wish we saw wider adoption of Bazel, or something Bazel-like, from the OSS space. The main benefits Bazel-like systems bring to the table, in my mind, are structuring libraries, binaries, and tests in a way a software engineer thinks about those things in code. It makes it very natural and also provides public/private visibility to libraries all while also giving you reproducible builds. If you are in a larger company, or something like an OS distribution, you can even further benefit from RBE. Imagine a Linux distro just being built like this: cc_binary(name = "package_manager", ...) os_pkg(name = "distro", srcs = [":package_manager", "//:userspace"]) Or something like that which would produce an iso and cpio (for PXE) automatically for you. You could then very quickly compile and test all of this on every arch you have access to using RBE.

oriolid 5y ago

Just out of curiosity, which packages do use Meson as wrapper over CMake? Sounds like total misuse but I'm interested in how it's done.

misnome 5y ago
Not specifically a wrapper, but it's built into Meson: https://mesonbuild.com/Dependencies.html#dependency-detection-method https://mesonbuild.com/Dependencies.html#dependency-detectio... > For dependencies without specific detection logic, the dependency method order for auto is: pkg-config cmake
- oriolid 5y ago
  Thanks. It's a fairly new feature, I didn't know about it. It's certainly annoying that distros don't have good pkg-config support, it would be so much nicer than writing detection logic or reusing CMake.
  - mathstuf 5y ago
    (FD: CMake developer) In my experience, it's that pkg-config assumes that everything needed to consume a library can be communicated via flags spelled as GCC spells them. There are many compilers which don't speak GCC on the command line. Some are popular (Intel and MSVC come to mind).
    - oriolid 5y ago
      Good point. I have always been thinking that the practical way with MSVC is to just embed everything into the project because everything else is too much work. Perhaps it's time to change that now.

nolta 5y ago

Yeah, i had the same reaction. For example, meson couldn't find pybind11 until i added `pybind11-config --cmakedir` to CMAKE_PREFIX_PATH.

ho_schi 5y ago

Why this packages doesn't provide pkg-config after so many years? On Linux literally every library comes with pkg-config readily available and the same is possible on Windows (MSYS2) and MacOS (that beer thing).

misnome 5y ago
Maybe if you are installing from a distro-provided central repository like debian and only using system package-managed sources, and nothing exotic. On a cursory check, the conda environment that we build off has 250 packages in, and only 60 .pc files. And to be fair, only 50 entries in lib/cmake, but a lot of the CMake dependency resolution is built into CMake (and does pkg-config support separated components as part of a package, like e.g. Boost which apparently has a 14-year-old unresolved ticket to add pkg-config support). All our "build from source" HDF5 installs don't have this either. Nor does debian have .pc files for their distribution of one of our key libraries (which we don't use via debian, but still....). This seems a very, very long way from "literally every library comes with pkg-config".

dundarious 5y ago

I have no issue with projects like meson using FindFoo.cmake packages in principle. The problem with CMake is that most such packages aren’t implemented via just an export, as in https://cmake.org/cmake/help/latest/guide/importing-exporting/index.html#exporting-targets https://cmake.org/cmake/help/latest/guide/importing-exportin... Such packages and exports are really just simple config files that I think can be safely treated as declarative — they become a perhaps uglier, but portable alternative to pkg-config. As such, having meson read them would be a smart move, and would be quite simple. Unfortunately, CMake doesn’t have a culture of creating/installing/using exports IME, and so you end up with enormous, complicated Find packages that do fancy bespoke dynamic search logic. THAT isn’t something I’d like a project like meson to lean on, but only because the goal should be to remove the need for such things, not depend on them further. CMake doesn’t help matters by making exports fiddly.

gravypod 5y ago

I really wish we saw wider adoption of Bazel, or something Bazel-like, from the OSS space. The main benefits Bazel-like systems bring to the table, in my mind, are structuring libraries, binaries, and tests in a way a software engineer thinks about those things in code. It makes it very natural and also provides public/private visibility to libraries all while also giving you reproducible builds. If you are in a larger company, or something like an OS distribution, you can even further benefit from RBE. Imagine a Linux distro just being built like this: cc_binary(name = "package_manager", ...) os_pkg(name = "distro", srcs = [":package_manager", "//:userspace"]) Or something like that which would produce an iso and cpio (for PXE) automatically for you. You could then very quickly compile and test all of this on every arch you have access to using RBE.