[QBS] On the use of "Depends" keyword

[Jake Petroules]

> On Sep 3, 2015, at 2:34 PM, NIkolai Marchenko <enmarantispam at gmail.com> wrote:
> 
> Expanding on the second question a little:
> 
> Let's say there is a client that only has sources for lib2 but not lib1. He only has lib1.dll
> He also has his own superproject that lib2 is a part of.
> Now, if he tries to compile lib2 it will produce him an unresolved lib1 dependency.
> He can't comment out the dependency too as it will break source doe for those who need it.
> 
> The only option he has is to make it a soft dependency: Depends {name: "lib1"; required:false}
> 
> And this is one of the real world situations in which the question arises: 
> If lib1 is made a soft dependency,  will "super" still build lib1 first? 
> "required: false" is kinda open to interpretation and this is not documented as far as I can see

The Depends.required property is documented here: http://doc.qt.io/qbs/depends-item.html <http://doc.qt.io/qbs/depends-item.html>

Whether a dependency is required or not will not affect build order (assuming it is present; if it isn't, it's the same as if the dependency wasn't there at all). For your use case you probably want something like the following:

-- in lib2.qbs --
Product {
    type: ["dynamiclibrary"]
    name: "lib2"
    Depends { name: "Qt.core" }
    Depends { name: "lib1"; required: false }
    Properties {
        condition: !lib1.present
        cpp.libraryPaths: ["C:/path/to/precompiled/libs/"]
        cpp.dynamicLibraries: ["lib1"]
    }
}

This way if no "lib1" product exists in your qbs project tree, it will link to the precompiled lib1 DLL, but if the source is available, it will build from source and use the result of that.

There is a qbs issue on JIRA somewhere about having a more generalized version of this process, among other things...

> On Fri, Sep 4, 2015 at 12:02 AM, NIkolai Marchenko <enmarantispam at gmail.com <mailto:enmarantispam at gmail.com>> wrote:
> Hi! I have a problem/misunderstanding/concern with Depends keyword in qbs.
> 
> Lets consider a project like this 
> 
> -- in project.qbs --
> Project{
> name:"super"
> references: ["lib1.qbs", "lib2.qbs"]
> }
> --in lib1.qbs -- 
> Product{
> type: "dynamicLibrary"
> name: "lib1"
> Depends{name: Qt.core}
> //assuming this exports some classes/functions
> }
> 
> --in lib2.qbs -- 
> Product{
> type: "dynamicLibrary"
> name: "lib2"
> Depends{name: "Qt.core"}
> Depends{name: "lib1"}
> }
> 
> 
> Ok, first a question: is Depends{name: "lib1"} in lib2.qbs the ONLY way currently available to enforce lib1 being built before lib2 when superproject is built?
> 
> if the answer is yes, then we have further questions:
> 1) 
> Depends{name: "Qt.core"} is telling qbs to make classes from qtcore available at compile time 
> Depends{name: "lib1"} is essentially a directve to the compiler to build lib1 first
> Isn't there an ambiguity of usage here?
> 
> 2) 
> assuming we are trying to build lib2 via its own .qbs file instead of as a part of "super" 
> we will get unresolved lib1 dependency even if lib1 was already compiled previously and lib1.dll is available.
> 
> We can do  Depends{name: "lib1"; required: false} but then, will "super" enforce lib1 to be compiled first or does required:false breaks this promise?
> 
> 3) assuming we have a lot of Depends in a file
> Depends{name: "lib1"}
> Depends{name: "lib2"}
> Depends{name: "lib3"}
> Depends{name: "lib4"}
> Depends{name: "lib5"}
> 
> doesn't it look like internal .qbs is stating things for external project essentially making assumptions about the way this lib is beng built? 
> 
> 
> _______________________________________________
> QBS mailing list
> QBS at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qbs

-- 
Jake Petroules - jake.petroules at petroules.com

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