Wouldn't it be more reasonable to implement something like OptionalDepends where you could just list all possible dependencies in the order in which it should be loaded?
On Tue, May 14, 2019 at 9:26 PM Иван Комиссаров <[email protected]> wrote: > I would like to discuss the way how external dependencies should be > searched by qbs. > > While implementing support for the protobuf I found that there several > place where a generic c++ can come from. > > 1. It can be detected via pkg-config > 2. It can be detected using probes > 3. Other pkg-config-like tools? Maybe Vcpkg? > 4. It can be the part of the project. > > I am not sure if we need to support 4, but if the mechanism of library > searching will be based on the Depends item, I don’t see why user can’t add > a «zlib» product that will be fetched prior to system modules. But anyway, > that’s not the point. > > The point is that for now, I have to write stuff like > > Depends { > > name: "internal.libprotobuf.pkgconfig" > > condition: _autoDetect > > required: false > > } > > Depends { > > name: "internal.libprotobuf.probes" > > condition: _autoDetect && !internal.libprotobuf.pkgconfig.found > > required: false > > } > > > Note, that libprotobuf.pkgconfig and libprotobuf.probes are *different* > modules > in different folders under qbs/modules. > In case I want to add third way to fetch a library, I will require third > module and third Depends item. Too much boilerplate for a modern build > system. > > This comes from the limitation that modules are loaded only based on their > condition and priority and it is not possible to use Probes in conditions. > I guess, this limitation comes from the fact that probes are heavy to > evaluate, but I’m not sure. > Either that limitation should be removed, or we can extend the way Qbs > loads modules by adding property bool recover to the Module which tells > Qbs to try loading next module in a chain (with lower priority) if loading > «best suitable» module failed. If the property is false by default, current > behavior will be preserved and we can use it to implement «chain» loading > by simply writing Depends { name: "internal.libprotobuf" }. > > Next thing I want to discuss is the way how Qbs should search for > libraries using Probes. For now, we have IncludeProbe, LibraryProbe and > FrameworkProbe (for macOS frameworks). It is not very convenient to use > them directly, but we can wrap them into a ExternalPackage module that > provides some input properties to tell Probes what to search for: > > ExternalPackage { > > name: "zlib" > > headers: ["zlib.h"] > > libraryNames: ["z"] > > } > > > We can also provide some properties to tell Qbs where to search for > libraries or to override some default behavior: > > qbs build modules.ExternalPackage.platformSearchPaths:"/opt/usr/lib" > modules.ExternalPackage.staticLibs:true > > That way, we will have mechanism similar to CMake find package module and > we can provide support for lot of libraries in a *declarative* way. > > Any thoughts? > _______________________________________________ > Qbs mailing list > [email protected] > https://lists.qt-project.org/listinfo/qbs >
_______________________________________________ Qbs mailing list [email protected] https://lists.qt-project.org/listinfo/qbs
