Let me use Cpp module as example.
We have macos-gcc.qbs:
DarwinGCC {
priority: 1
condition: qbs.targetOS.contains('macos') &&
qbs.toolchain && qbs.toolchain.contains('gcc')
}
And we have UnixGCC.qbs:
GenericGCC {
priority: -50
condition: qbs.toolchain && qbs.toolchain.contains("gcc")
}
Both conditions are true on macOS, so we will try loading only macos-gcc since
it has higher priority.
If loading it fails, we’re done here (which is perfectly reasonable for the cpp
module), we won’t try loading UnixGCC.
I suggest adding something like
DarwinGCC {
recover: true
}
So Qbs will try to load next module with lower priority (UnixGCC).
For real-world example, like zlib, the chain can be like «try pkg-config, if it
fails, try detecting via probes».
The goal is to have something like this on the client-side:
Depends { name: "zlib"; minimumVersion: "1.2.3.4" }
Not this:
Depends { name: «zlib.pkgconfig"; minimumVersion: «1.2.3.4»; required: false }
Depends { name: «zlib.probes"; condition: !zlib.pkgconfig.found;
minimumVersion: «1.2.3.4"; required: false }
> 14 мая 2019 г., в 22:44, NIkolai Marchenko <[email protected]>
> написал(а):
>
> > by adding property bool recover to the Module which tells Qbs to try
> > loading next module in a chain
> Probably needs a code example of a proposed solution. What is a "chain" like
> in this case?
>
> On Tue, May 14, 2019 at 11:32 PM Иван Комиссаров <[email protected]
> <mailto:[email protected]>> wrote:
>> On Tue, May 14, 2019 at 11:09 PM NIkolai Marchenko <[email protected]
>> <mailto:[email protected]>> 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?
>>
>
> This doesn’t solve the problem of the boilerplate code, you're suggesting to
> add some syntax sugar.
>
> However, it might be useful to specify the order in which
> probes/pkg-config/whatever are used (or even disable one of them).
>
> Maybe, this can be done via product/module properties, something like
>
> products.MyProduct.pkgconfig.condition:false
>
> There are some corner cases when you’re searching for libs A and B and you
> want to use pkg-config for lib A and probes for lib B… Not sure if it’s worth
> supporting that case.
>
>> 14 мая 2019 г., в 22:14, NIkolai Marchenko <[email protected]
>> <mailto:[email protected]>> написал(а):
>>
>> 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. .
>>
>
> For pkg-config, I don’t see such feature; it assumes that you’re set up paths
> so it won’t find wrong lib (paths like sysroot).
>
> For Qbs itself, LibraryProbe should check for the desired architecture and
> discard incompatible libraries. I don’t see any problems implementing this.
> It should also have a property to be able to choose between static/dynamic
> libraries. It’s quite dumb for now, actually=)
_______________________________________________
Qbs mailing list
[email protected]
https://lists.qt-project.org/listinfo/qbs
