| Yes definitely! The biggest time sink when porting a package was to research a projects requirements and dependencies. To our surprise only a handful projects do this correctly. If we could agree on a standard that captures the dependencies and requirements of a C++ project correctly it would be a huge win for the community. Currently there is no buildsystem that enables users to describe the requirements of an project correctly. We choose to support buck as a buildsystem mainly because it allows us to describe nicely the structure of a project. However like any other buildsystem it does not capture the full essence of a C++ project. For instance there is no way to describe the set of compatible compiler and linker flags. Many build systems evolved to be turing complete so we can write logic to handle various combination of options(eg. no-rtti) but this makes it really hard to reason about projects. It turned out to be quite challenging to determine if two projects are compatible with each other - in fact it turned out to be as challenging as solving the halting problem. Is this really necessary? I analyzed now over 300 c++ projects and I still haven't seen one project that truly needed a touring complete buildsystem to be build (Not even LLVM&Clang). So yes - I'm convinced a metadata file as you suggested is the way to go. |
We want to steer away from standardizing a build system for now. The uses cases are enormous to try to tackle. Instead, it would be simpler to standardized the description of the build environment so the package manager can pass that to the build system.
Hopefully, build systems will be updated to read the package metadata so it can properly consume the dependencies correctly.
> So yes - I'm convinced a metadata file as you suggested is the way to go.
Good to know we are on the right track.