Re: [Qbs] pre-built products (cont.)

[Joerg Bornemann]

On 24/09/2017 13:53, Christian Gagneraud wrote:

[...]

and so on. Or you cram all platforms into one file - as you like.

We should have a documentation page covering this use case. I've created
QBS-1191 for that.


Cool, but what (should) happen in case of several
$projectroot/modules/ThirdParty/lib1/*.qps matches?
Or none matches, for the matter?


Excellent question. If none matches, the module cannot be loaded. You 
will get an error message. If multiple files (module instances) match, 
then the current situation is that "the first one" wins. That means, it 
is currently important to keep the conditions mutually exclusive.


We got away with this non-design until now, but in 1.10 this will change 
to: multiple matching module instances are an error.
You will also be able to define an order for the instances by setting 
priorities. The matching instance with the highest priority is chosen. 
The exact formulation for the new behavior is: multiple matching module 
instances with the same priority are an error.


See QBS-61 and related patches for more information.


Cheers,

Joerg
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] pre-built products (cont.)

[Joerg Bornemann]

On 10/09/2017 03:44, Christian Gagneraud wrote:


In my source tree I have pre-built binaries, these are third-party
library that we get in binary form only. (PS: don't tell me that it is
bad, i already know that. I cannot change that, i have to deal with
it)


Even if it's bad we cannot ignore this situation. Some hardware vendors 
only provide binary libraries to talk to their devices.


[...]


So I would like to have a product for each of these, that would export
a include path, a lib search path and a lib name.
But of course i don't want these product to be built, because i don't
have the source code.

The reason i'm thinking about using the product item is that i can
then simply add references to the dependings product.

Is it the right approach?


While this works, you don't need to use a product. A module would be 
more "natural". Effectively, the Export item you're writing already 
defines a module with the same name as the product.



Maybe i should come with a Module approach, eg, something similar to
Qt itself, that would allow me to add:

Depends {
name: "ThirdParty"
submodules: [
   "lib1", "lib2", ...
]
}

I never tried that, not sure how to get started...


You would create a folder structure like this

$projectroot/modules/ThirdParty/lib1
$projectroot/modules/ThirdParty/lib2

and create $projectroot/modules/ThirdParty/lib1/x86.qbs
$projectroot/modules/ThirdParty/lib1/x86_64.qbs

with the content

---x86.qbs---
Module {
condition: qbs.architecture === "x86"
Depends { name: "cpp" }
cpp.dynamicLibraries: ["somewhere/x86/lib1.lib"]
}
---

---x86_64.qbs---
Module {
condition: qbs.architecture === "x86_64"
Depends { name: "cpp" }
cpp.dynamicLibraries: ["somewhere/x86_64/lib1.lib"]
}
---

and so on. Or you cram all platforms into one file - as you like.

We should have a documentation page covering this use case. I've created 
QBS-1191 for that.




Joerg
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] pre-built products (cont.)

[Christian Gagneraud]

On 10 September 2017 at 13:44, Christian Gagneraud  wrote:
> [sorry, hit send by mistake, please ignore my previous message]
>
> Hi there,
>
> In my source tree I have pre-built binaries, these are third-party
> library that we get in binary form only. (PS: don't tell me that it is
> bad, i already know that. I cannot change that, i have to deal with
> it)
>
> Each of these third party comes with a set of binaries that correspond
> to the different toolchain/targets that we support.
>
> A typical tree is:
> $topdir/ThirdParty/$name/include
> $topdir/ThirdParty/$name/lib/$os$arch/$libname.{so,dll,lib}

OK, for now i'm using a raw Product item, that only contains an Export
Item, that in turn sets cpp.includePaths, cpp.libraryPaths,
cpp.defines, ...
It works well enough.

Once i got this project ported to Qbs, i will investigate the
Depends.submodules thing

Chris

>
> So I would like to have a product for each of these, that would export
> a include path, a lib search path and a lib name.
> But of course i don't want these product to be built, because i don't
> have the source code.
>
> The reason i'm thinking about using the product item is that i can
> then simply add references to the dependings product.
>
> Is it the right approach?
>
> Maybe i should come with a Module approach, eg, something similar to
> Qt itself, that would allow me to add:
>
> Depends {
>name: "ThirdParty"
>submodules: [
>   "lib1", "lib2", ...
>]
> }
>
> I never tried that, not sure how to get started...
>
> Thanks,
> Chris
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs