Hi Oswald and Richard, Thank both of you for your replies.
Some packages I need are not available on bintray. Therefore I need to download those packages on GitHub. Do you think I can use Network Access API of Qt to download files and QByteArray::qUncompress to uncompress files in Qbs code? br, Vincent On Mon, 5 Aug 2019 at 23:42, Richard Weickelt <rich...@weickelt.de> wrote: > > >> 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 >
_______________________________________________ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs