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
