[Qbs] External Dependencies

[NIkolai Marchenko]

And while we are on the subject of finding libs. Is it possible to somehow
indicate that a library you are trying to link isn't compatible with the
compiler? Somethe _other_ than "unresolved external" error that can
indicate anything from lib not being where you want it to be, a mistype in
the path, incorrect lib version or, indeed, binary incompatibility. .

On Tue, May 14, 2019 at 11:09 PM NIkolai Marchenko <enmarantispam at gmail.com>
wrote:

> 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/63a8664b/attachment.html>