[Qbs] External Dependencies

[NIkolai Marchenko]

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 Иван Комиссаров <abbapoh at gmail.com> 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
> Qbs at qt-project.org
> https://lists.qt-project.org/listinfo/qbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qbs/attachments/20190514/20c56802/attachment-0001.html>