>> Another automated and platform-independent library interface would be Conan >> or vcpgkg. Have you searched for packages on bintray? >> > these are some of the services that would need wrapping.
Why would you wrap these tools with Qbs and not use them side-by-side or - the other way round - use them as a wrapper for Qbs? It is my understanding that configuration/dependency/package management sits on top of build automation. Conan provides a recipe containing versions and configuration options for each dependency. It downloads all dependencies and generates something that can be consumed by your build system. In case of Qbs, see https://docs.conan.io/en/latest/integrations/build_system/qbs.html. That defines a sharp boundary between build automation and configuration/dependency/package management. I don't say that Conan is particularly beautiful, but I think it's a reasonable approach. I haven't used vcpkg. Is it different? >> If all that is not an option, then you might implement your own download & >> install solution. >> > i would recommend that "your own" be something contributable upstream, > to get https://bugreports.qt.io/browse/QBS-62 resolved. > > note that a key feature for configuration management is the ability to > pin the sources and versions of modules, which is why the "grown-ups" > from the java world (at least maven and bazel, and i presume also > gradle) support it. conversely, linux distributors *hate* it - they want > abstract package names and ranges of acceptable versions, based on > binary compatibility promises. a good implementation would permit strict > and relaxed operation with the same project files, and per-module > overrides from the outside to support selective unbundling (see also > QBS-61). Given the current manpower behind Qbs, I have serious doubts that this is going to happen any time soon. Richard _______________________________________________ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
