Ah, sorry I accidentally only replied to Christian. Here's the original message:
Here's the probe. I is instantiated at project level where the value of
'generatedQbsFilePath' is added to the 'references' property.
If you run it like this, 'targetArch' will be undefined.
Probe {
property path conanFile
readonly property string targetArch: qbs.Architecture
readonly property string buildType: qbs.buildVariant === "debug" ?
"Debug" : "Release" // Conan's build_type is case-sensitive!
readonly property path conanPackageDir:
FileInfo.joinPaths(FileInfo.canonicalPath("."), qbs.configurationName, "conan")
readonly property path generatedQbsFilePath:
FileInfo.joinPaths(conanPackageDir, "/conanbuildinfo.qbs")
configure: {
/*...*/
var process = new Process();
process.setWorkingDirectory(conanPackageDir);
process.exec("conan", ["user", "test", "-p", "test123"], true);
process.exec("conan", ["install", conanPackageDir, "-s",
"build_type=" + buildType, "-s", targetArch], true);
console.info(process.readStdOut());
found = true;
}
}
>> readonly property string targetArch: qbs.Architecture
>You have a typo here (the 'a' should be lower-case). (If this is not the real
>code: Please make sure to always copy-paste, not type up some approximation).
Yeah, sorry that was a typo. It's the real code, I only added the arch property
for the example because I'm not using it currently since it's not working.
> Though it will still work if you set the architecture via a profile.
How would I access a property set in a profile? I think I've tried it before
but I probably did something wrong.
Also in the blog post about the release of qbs 1.15.0 it says the following:
Probes on the project level are now evaluated before Profile items. That way a
Qbs project can easily interface to package managers like Conan or vcpkg and
resolve all build dependencies including compiler toolchains in a clean and
platform-agnostic way. [...]
Doesn't that mean that profile specific properties are inaccessible at the time
the probe is evaluated?
> Note that such an architecture-agnostic Conan probe breaks if you are going
> to multiplex a product over different architectures
At the moment I'm not using multiplexing but that is a good point and something
to consider.
> In that case it would
> better to put the probe into the product or even a separate module. Make
> every product in your project depend on that module.
How would I reference the qbs file generated by conan though? I'm only doing it
with this project level probe because I thought there was no other way, or is
there?
Leon
On 1/30/20, 1:28 PM, "Qbs on behalf of Richard Weickelt"
<qbs-boun...@qt-project.org on behalf of rich...@weickelt.de> wrote:
>> Here's the probe. I is instantiated at project level where the value of
>> 'generatedQbsFilePath' is added to the 'references' property.
Leon, would you please post your probe code to the mailing list? I am
generally interested in Qbs Conan integration and would like to see how
others do it.
> That's generally a problem. Modules are per-product, and with very few
> exceptions (constants like qbs.hostOS) will not have proper values on the
> project level. Though it will still work if you set the architecture via
> a profile.
If you know what architecture your project will be built for, specify a
project property and set this from command line (or in Qt Creator).
Note that such an architecture-agnostic Conan probe breaks if you are going
to multiplex a product over different architectures. In that case it would
better to put the probe into the product or even a separate module. Make
every product in your project depend on that module. The probe should only
run a single time for the whole project. Then you should be able to use
properties from the qbs module as inputs of the probe.
Richard
_______________________________________________
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
_______________________________________________
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
