[Qbs] External Dependencies

[Иван Комиссаров]

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 <enmarantispam at gmail.com> написал(а):
> 
> > 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 Иван Комиссаров <abbapoh at gmail.com <mailto:abbapoh at gmail.com>> wrote:
>> On Tue, May 14, 2019 at 11:09 PM NIkolai Marchenko <enmarantispam at gmail.com <mailto: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?
>> 
> 
> 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 <enmarantispam at gmail.com <mailto:enmarantispam at gmail.com>> написал(а):
>> 
>> 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=)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qbs/attachments/20190514/a700017b/attachment.html>