rochus-keller
How to check for dependencies?
Both CMake and Autotools have the ability to check for dependencies (e.g: zlib, libpng,...). How could I do that with BUSY?
There is a trycompile built-in function, but I'm not yet happy with it. GN has a exec_script function which I was thinking of adapting, but I never required it so far.
Can you make an example on how you would like to use such a function?
The FOX Toolkit: http://www.fox-toolkit.org/
Original used Autotools. But people found Autotools sucks, so they created the build scripts for their favorite build systems:
CMake: https://github.com/devinsmith/fox
Meson: https://github.com/franko/fox
I wanted to create a BUSY build script for the FOX Toolkit. You could read the build scripts for other build systems, the FOX Toolkit required several external libraries.
Ok, I see. The dependency systems of Meson or CMake are likely beyond the scope of BUSY in its current incarnation. The phylosophy of these systems is something like "just press one button and the build system builds something which is determined by the (random) configuration at hand on the current machine"; BUSY on the other hand only does what it is explicitly told, which includes the libraries to be expected, and fails the build if these are not found.
That was my first look; let me take a second look these days.
The dependency resolution features of CMake and Meson seem to have quite a complexity, and even though there is a supporting community, I still find situations where it doesn't seem to work (e.g. dotnet runtime with the icu libs). The effort to attain an maintain compatibility to an unbounded number of platforms, package managers and versions is too much for the current incarnation of this project.
So for the time being the non-goal "BUSY doesn't search for libraries or toolchains and doesn't download anything; it uses what you give it" remains valid.
I will improve trycompile and add more features useful to implement library/version detection from specific BUSY files, but this needs more input and some patience.
The dependency resolution features of CMake and Meson seem to have quite a complexity
If you just stick with "allow pkg-config dependencies" this should be quite manageable. CMake is complex because it has two unconnected approaches:
- a turing-complete file that is sourced in order to search for libraries and perform whatever other turing-complete work is necessary to create an imported dependency
- pkg-config support
Meson is mostly complex because it provides one function that is allowed to use either pkg-config or dispatch to a dummy cmake project which reads the cmake debug traces (!!!) to get access to the data imprisoned in cmake's turing-complete dependency finders. This is a nod to practicality which may be beyond the scope of BUSY. I don't recommend jumping down that rabbit hole without a lot of preparation. Any decent library dependencies should already be using pkg-config anyway, since that was literally designed for interoperability between build systems.
Thanks. Anyway this kind of dependency localization and resolution is currently not in the scope of BUSY. Using pkg-config as you suggest might be feasible, but remember that the goal is to enable also Windows and Macos builds. Even today it is possible to run scripts to interact e.g. with Conan or Vcpkg if need be. But of course this somewhat collides with the original purpose of BUSY to enable green-field bootstrapping. For my projects I either add the dependency to the source tree or instruct the users to download and unpack dependencies to a common directory where BUSY easily can find it.
Using pkg-config as you suggest might be feasible, but remember that the goal is to enable also Windows and Macos builds.
Well, it works quite well on macos and is widely used there. :)
It's also possible to install and use on Windows, though it is less streamlined there...
Well, it works quite well on macos and is widely used there.
Ok, I see; but isn't it a separate package manager to the mostly used Homebrew system, and is there really a selection of packages comparable to the latter? And I guess it's neither very established on Windows? I'm not a reference, but I wasn't aware of this package management system for this two platforms so far.
Ok, I see; but isn't it a separate package manager to the mostly used Homebrew system, and is there really a selection of packages comparable to the latter?
Homebrew is comparable to apt/dpkg/rpm, and those don't compete with pkg-config either.
Homebrew ships a pkg-config package, as do apt/dpkg/rpm, and any software that requires and uses pkg-config to build on Linux or BSD, also does so with homebrew. That's a lot of software.
And I guess it's neither very established on Windows?
Unfortunately nothing is very established on Windows. :D The standard there is, indeed, to vendor your dependencies and build them as part of your own meson/cmake/BUSY scripts.
Ok, I see, thanks; I ought to look more into the internals of package managers. Anyway, if the concept doesn't work on all platforms (including Windows) then it's likely not in the scope of BUSY; but I should add a way to run scripts and fetch the result during the analysis phase, i.e. like exec_script in GN; then a BUSY file could call e.g. pkg-config and set paths and flags accordingly; it would then be in the responsibility of the BUSY file author to handle Windows.