Re: [Qbs] Failed 'PackageBuild' product on QBS 1.22
>> Did you remember to connect the "package-build-file" tag to your
>> product type? Either by making this tag the product type or via a
>> chain of rules.
> I didn't do it, because I don't understand how to do it.
So for example you could do this:
```
Product {
name: "ToxPhone"
type: [ /* maybe some other types here… */ "package-build-file" ]
// …
```
This will cause your rule to be executed because the product “ToxPhone”
requires it because it is of the type produced by your rule.
See also https://qbs.io/docs/qml-qbslanguageitems-rule/#rules-and-product-types
Best
Jochen
Von: Qbs im Auftrag von Карелин Павел
Datum: Dienstag, 10. Mai 2022 um 18:27
An: qbs@qt-project.org
Betreff: Re: [Qbs] Failed 'PackageBuild' product on QBS 1.22
10.05.2022 17:49, Christian Kandeler пишет:
>
> On 5/10/22 15:02, Карелин Павел wrote:
>>
>>
>> 05.05.2022 12:14, Christian Kandeler пишет:
>>> On 5/5/22 11:00, Карелин Павел wrote:
05.05.2022 10:47, Christian Kandeler пишет:
> On 5/4/22 18:18, Карелин Павел wrote:
>> Christian, how would you solve my problem?
>> After the project is built, the deb-package is assembled. To
>> build the deb-package, you need a list of dependent libraries
>> (not all, only parts, system dependencies no required). For
>> example this list:
>>
>> /opt/ffmpeg/4.4/lib/libavutil.so*
>> /opt/ffmpeg/4.4/lib/libswscale.so*
>> /opt/ffmpeg/4.4/lib/libswresample.so*
>> /opt/opencv/4.5.5/lib/libopencv_core.so*
>> /opt/opencv/4.5.5/lib/libopencv_calib3d.so*
>> /opt/opencv/4.5.5/lib/libopencv_imgproc.so*
>>
>> I can get library paths and names of so-modules from dependencies:
>>
>> Depends { name: "lib.ffmpeg" }
>> Depends { name: "lib.opencv" }
>>
>> How can I create such a list and put it in the package_build_info
>> file? With the rules?
> lib.ffmpeg and lib.opencv are modules in your projects?
Yes, they are modules. I use my own QBS-extensions to include
third-party assembled libraries in my projects
(https://github.com/hkarel/QbsExt/tree/master/modules/lib).
>>>
>>> Then I think the correct way is to
>>>
>>> - collect these libraries in a Group in the respective module
>>>
>>> - mark them as target artifacts (see
>>> https://doc.qt.io/qbs/qml-qbslanguageitems-group.html#filesAreTargets-prop)
>>>
>>> - give them a suitable tag
>>>
>>> - on the consuming side, create a rule whose
>>> inputsFromDependencies matches that tag and in this rule, do
>>> whatever you need to do.
>>
>> Tried to follow you recommendation:
>>
>> --- LibModule ---
>> Module {
>> id: libmod
>> property string prefix
>> property string version: ""
>>
>> property bool enabled: true
>> property bool useSystem: false
>>
>> property string includeSuffix: "/include"
>> property string libSuffix: "/lib"
>>
>> property path includePath: (useSystem || !enabled)
>>? undefined
>>: prefix + (version.length ? "/" +
>> version : "") + includeSuffix
>>
>> property path libraryPath: (useSystem || !enabled)
>>? undefined
>>: prefix + (version.length ? "/" +
>> version : "") + libSuffix
>>
>> property var dynamicLibraries: ["sodium"]
>> property var staticLibraries: []
>> ...
>> Group {
>> //name: "package-build"
>> fileTags: "package-build"
>> filesAreTargets: true
>> files: {
>> var libfiles = [];
>> if (!libmod.useSystem && libmod.enabled)
>> for (var i in libmod.dynamicLibraries) {
>> libfiles.push(
>> libmod.libraryPath +
>> ("/lib{0}.so*").format(libmod.dynamicLibraries[i]))
>> }
>>
>> console.info("=== libfiles ===");
>> console.info(libfiles);
>>
>> return libfiles;
>> }
>> }
>> } // Module
>>
>> LibModule {
>> id: sodium
>> version: "1.0.x"
>> prefix: "/opt/sodium"
>> checkingHeaders: ["sodium.h"]
>> dynamicLibraries: ["sodium"]
>> staticLibraries: ["sodium"]
>> }
>>
>> Product {
>> name: "ToxPhone"
>> ...
>> Depends { name: "lib.sodium" }
>> ...
>> lib.sodium.version: project.sodiumVersion
>> //lib.sodium.useSystem: project.useSystemSodium
>>
>> Rule {
>> id: pkgbuild
>> //inputs: ["package-build"]
>> inputsFromDependencies: ["package-build"]
>>
>> Artifact {
>> fileTags: ["package-build-file"]
>> filePath: FileInfo.joinPaths(project.buildDirectory,
>> "package_build_info")
>> }
>> prepare: {
>> var outputFile =
>> FileInfo.joinPaths(project.buildDirectory, "package_build_info");
>>
>> console.info("=== outputFile ===");
>> console.info(outputFile);
>> }
>> }
>>
Re: [Qbs] Build and run a AuxiliaryApplication before build a MainApplication
> I can create a micro-project that emulates this situation. Yeah I think this would help. It might even help you understand what exactly triggers the issue and then it's easier to determine if this is a Qbs bug or a problem in your project. Best Jochen Ulrich ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Specify custom applications and application arguments in qbs project
PS: And if you want to run an executable which is built as part of your project, then the product should of course depend on that executable to make sure it is built before. And the rule should use the executable's `Product.targetName` and ` Product.destinationDirectory` properties to determine the path of the executable. Best Jochen ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Specify custom applications and application arguments in qbs project
Hi Yury!
> I want to specify in the qbs project that there are several predefined
> command line arguments which will be visible as separate runnables in
> QtCreator.
The "several predefined command line arguments" parts should be possible by
writing a Product with a corresponding Rule.
Something like this (UNTESTED!):
Product {
name: "my-command"
type: [ "command" ]
builtByDefault: false
Rule {
multiplex: true
alwaysRun: true
inputs: []
Artifact {
filePath: "dummy"
fileTags: [ "command" ]
}
prepare: {
let cmd = new Command();
cmd.description = "Running my-command";
cmd.program = "path/to/my-command";
cmd.arguments = [ "--arg1", "--arg2" ];
return cmd;
}
}
}
Then, *building* the product "my-command" will run the command.
Maybe you need to tune the Rule's properties to have it work as expected (as
written above: this is untested).
See also https://doc.qt.io/qbs/qml-qbslanguageitems-rule.html and
https://doc.qt.io/qbs/commands.html for more info.
However, this won't show up as a runnable in QtCreator because the execution of
the command is happening as a build step and there is no artifact to be
executed after building.
But "my-command" would show up in QtCreator's project view and there it could
be triggered by right-click -> Build.
Maybe that's good enough for you?
Best
Jochen
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] How to use texttemplate module?
> wouldn't it be a good idea to add > > additionalProductTypes: [product.texttemplate.outputTag] > > to the texttemplate module? I think that's wrong. Because if the output of the text template should be processed further (for example, it creates a .cpp file which should be compiled into an application or library), then the output artifacts need to have a corresponding tag set via the ` texttemplate.outputTag` property. And if the texttemplate module would set `additionalProductTypes: [product.texttemplate.outputTag]` then the Product containing the template would also get these tags (for example "cpp") which is wrong (it's an application/library, not a cpp file). Best Jochen ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] How to use texttemplate module?
Hi Alberto
> But if I modify that file and change the Product type from "text" to
> "application", then the rule is no longer run.
Yeah, this is how the rules in Qbs work: they are only executed if there is a
Product or another Rule which "requests" them to be run.
Meaning: There must be a Product which has the tag of the output artifacts (the
artifacts are the product) or a Rule which takes the artifacts as input (the
artifacts are processed further).
So if the output of the texttemplate processing does not need to be processed
further by Qbs, then you should put it into a separate product with the type
"text".
If the output should be processed further (for example you are replacing text
inside a .cpp file which should then be compiled into your application),
then you should set the texttemplate.outputTag (see
https://doc.qt.io/qbs/qml-qbsmodules-texttemplate.html#outputTag-prop)
accordingly.
For example:
Product {
name: "bar"
type: ["application"]
Depends { name: "texttemplate" }
Depends { name: "cpp" }
texttemplate.dict: ({
bar: "BAR",
})
files: ["main.cpp.in"]
texttemplate.outputTag: "cpp"
}
In the example, the rule from the texttemplate module will create an artifact
"main.cpp" which is tagged with "cpp" which causes it to be picked up by the
cpp module.
Best
Jochen
Am 08.09.20, 23:25 schrieb "Qbs im Auftrag von Alberto Mardegan"
:
Hi all,
I'm having some trouble using the texttemplate module, because I
cannot get its rule to execute.
If I run the test file from
https://code.qt.io/cgit/qbs/qbs.git/tree/tests/auto/blackbox/testdata/texttemplate
then everything works.
But if I modify that file and change the Product type from "text" to
"application", then the rule is no longer run.
I also tried to add
Group {
fileTagsFilter: ["text"]
qbs.install: true
}
to the QBS file, but still the texttemplate rule is not executed. Of
course, in my project the product type is not "text" (I have a
QtGuiApplication), so how can I tell QBS that it should run all the
rules which produce a "text" artifact?
Ciao,
Alberto
--
http://www.mardy.it - Geek in un lingua international
___
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
Re: [Qbs] How to get the full dependency name in a ModuleProvider?
No, I didn't file issues in JIRA yet because there is a discussion going on regarding a different way to handle external dependencies. See https://codereview.qt-project.org/c/qbs/qbs/+/297830 So it's not clear to me yet if the Conan integration will be based on ModuleProviders or on that Package mechanism. Best Jochen Am 31.07.20, 13:27 schrieb "Alberto Mardegan" : Il 31.07.2020 11:28, Jochen Ulrich ha scritto: > We also stumbled over this and a few more shortcomings of ModuleProviders when writing a ModuleProvider to integrate the Conan package manager with Qbs. > See this thread: https://lists.qt-project.org/pipermail/qbs/2020-February/002649.html Interesting! You didn't find these as issues in JIRA< did you? At least, I couldn't find them out of a quick search. Ciao, Alberto ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] (no subject)
Hi! > Is qbs supposed to work with Qt WebAssembly (I cannot get it to work)? No, at the moment Qbs does not provide support for WebAssembly. However, since you can do anything with Qbs, it should be possible to get it to work as well. __ In the end, it boils down to writing a Module that provides Rules to process the input files as required. Probably, this Module should derive from the CppModule?! You can have a look at the internals of the CppModule here: https://code.qt.io/cgit/qbs/qbs.git/tree/share/qbs/modules/cpp Unfortunately, I have no knowledge of WebAssembly so I cannot help with the details. :-/ > If not, are there plans to add support? I don't think there are any plans yet. Contributions are welcome, of course. __ Best Jochen ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] How to get the full dependency name in a ModuleProvider?
Hi! > it does not look like there is any way to get the full dependency name We also stumbled over this and a few more shortcomings of ModuleProviders when writing a ModuleProvider to integrate the Conan package manager with Qbs. See this thread: https://lists.qt-project.org/pipermail/qbs/2020-February/002649.html Best Jochen ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Building a product's files into another product
Hi Alberto!
Did you try using a Module instead of a Product?
https://doc.qt.io/qbs/qml-qbslanguageitems-module.html
https://doc.qt.io/qbs/custom-modules.html
Module {
Depends { name: "cpp" }
Group {
name: "a"
files: [ "one.cpp" ]
}
}
Or export from a Product (which also creates a Module internally):
Product {
name: "a"
Export {
Depends { name: "cpp" } // Maybe not needed?!
Group {
name: "a sources"
files: [ "one.cpp" ]
}
}
}
Not sure if this works, though. :-)
Best
Jochen
Am 29.07.20, 22:52 schrieb "Qbs im Auftrag von Alberto Mardegan"
:
Hi!
The subject is a bit convoluted, but the meaning is this one: I have
product A defined like this:
Product {
type: "linkme"
name: "a"
Depends { name: "cpp" }
files: ["one.cpp"]
}
(in reality, the situation is more complex than this and the input files
are static files with the "qt.core.resource_data" tag, which causes a
"qrc_a.cpp" to be generated)
And I'm trying to use it from a product B:
CppApplication {
name: "b"
Depends { name: "a" }
...
}
Now, I would like that the cpp files from product A would be used when
building product B, that is as if product A was a Group. But it looks
like the Depends item is not effective.
I also tried to change the product's type to "obj", and this at least
causes the files in product A to be compiled; but they are still not
added to product B.
Indeed, it all works if I change product's A type to "staticlibrary",
but that forces me to use Q_INIT_RESOURCE, which I was trying to avoid.
Any ideas?
(the reason why I'm using a product and not a Group is that, under some
configurations, this could indeed be a separate product like a loadable
module)
Ciao,
Alberto
--
http://www.mardy.it - Geek in un lingua international
___
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
Re: [Qbs] Conditionally adding a file tag
Hi Alberto!
I guess the issue here is that FileTaggers are disabled in this case:
> File taggers are disabled if file tags are set explicitly in a product or
> group.
> For example, the "cpp" tag is not attached to the .cpp files in the following
> product
(see https://doc.qt.io/qbs/qml-qbslanguageitems-filetagger.html#details)
I don't know why the behavior is like this.
But it seems you need to decide to either set the tags via a Group or via a
FileTagger.
But normally, it is not a problem to set those tags via a Group when organizing
the Groups accordingly.
For example you could have a dedicated Group for those resources. Something like
Group {
name: "Resources"
fileTags: embedAsResource ? ["qt.core.resource_data"] : []
qbs.install: !embedAsResource
qbs.installDir: "share/" + project.relativePluginDir
qbs.installSourceBase: "../"
files: [
"file1.qml",
"file2.qml",
"file3..png",
"file4.gif",
]
}
Best
Jochen Ulrich
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] QBS script parsing speed
Nice! It brings a ~44% speed improvement in the problematic case according to your numbers: > Resolving withLeafExports/9-2-implicit real0m43.592s real0m24.494s Thanks, Richard! So for "medium" projects in terms of depth of the dependency tree, it's sensible to use transitive dependencies now: withLeafExports/4-8-implicit: real0m18.180s vs. withAdditionalDepends/4-8-explicit: real0m19.319s However, for "large" projects, the workaround still seems to be 25% faster: withLeafExports/9-2-implicit: real0m24.494s vs. withAdditionalDepends/9-2-explicit: real0m18.149s Best Jochen Am 30.06.20, 15:09 schrieb "Richard Weickelt" : Jochen, >> Well [the time] goes into "Handling Products". So it is ModuleLoader::handleProduct(). >> And there, it could be the ModuleMerger. But speculation is dangerous when discussing about performance. > See https://lists.qt-project.org/pipermail/qbs/2019-August/002546.html > > You can find my test results together with the scripts to generate the projects here: > https://gist.github.com/j-ulrich/35f345007809c77403a8ee88f4d9db11#file-results-md Then you might be happy to hear that the ModuleMerger was completely rewritten for Qbs 1.16.0 (https://codereview.qt-project.org/c/qbs/qbs/+/284737). Running your benchmark with Qbs 1.16.0 (Qt Creator 4.12) gives me significantly better results in case of transitive dependencies. See below. I am not sure whether this has any noticable effect on real-world projects. But if ModuleMerger was ever a bottleneck, then it should not longer be. - i5-2520M CPU @ 2.50GHz Xubuntu 16.04) First line: Qbs 1.15.1 Second line: Qbs 1.16.0 > Resolving 4-8-direct real0m3.089s real0m2.669s > Resolving 4-8-implicit real0m4.808s real0m3.409s > Resolving 4-8-explicit real0m3.898s real0m3.085s > Resolving withLeafExports/4-8-direct real0m16.508s real0m13.793s > Resolving withLeafExports/4-8-implicit real0m25.907s real0m18.180s > Resolving withLeafExports/4-8-explicit real0m21.393s real0m15.844s > Resolving withLeafExports/9-2-direct real0m13.992s real0m10.750s > Resolving withLeafExports/9-2-implicit real0m43.592s real0m24.494s > Resolving withLeafExports/9-2-explicit real0m26.019s real0m17.589s > Resolving withAdditionalDepends/4-8-direct real0m25.096s real0m18.892s > Resolving withAdditionalDepends/4-8-implicit real0m28.369s real0m19.868s > Resolving withAdditionalDepends/4-8-explicit real0m29.164s real0m19.319s > Resolving withAdditionalDepends/9-2-direct real0m19.110s real0m17.264s > Resolving withAdditionalDepends/9-2-implicit real0m20.887s real0m19.269s > Resolving withAdditionalDepends/9-2-explicit real0m18.359s real0m18.149s > Resolving 9-2-direct real0m2.500s > Resolving 9-2-implicit real0m6.393s > Resolving 9-2-explicit real0m3.833s real0m2.326s ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] QBS script parsing speed
My analysis back then was: > Well [the time] goes into "Handling Products". So it is > ModuleLoader::handleProduct(). > And there, it could be the ModuleMerger. But speculation is dangerous when > discussing about performance. See https://lists.qt-project.org/pipermail/qbs/2019-August/002546.html You can find my test results together with the scripts to generate the projects here: https://gist.github.com/j-ulrich/35f345007809c77403a8ee88f4d9db11#file-results-md Best Jochen ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] QBS script parsing speed
We faced similar problems but our resolve times were even higher (30 s to 2
mins).
We were able to work around this and significantly reduce the resolve times by
avoiding transitive dependencies (meaning exporting dependencies).
So instead of this:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Product {
name: “A”
Depends { name: "B" }
}
Product {
name: “B”
Depends { name: "C" }
Export {
Depends { name: "C" }
}
}
Product {
name: “C”
Depends { name: "SomeLibNeededEverywhere" }
Export {
Depends { name: "SomeLibNeededEverywhere" }
}
}
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
You do it like this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Product {
name: “A”
Depends { name: "B" }
Depends { name: "C" }
Depends { name: "SomeLibNeededEverywhere" }
}
Product {
name: “B”
Depends { name: "C" }
Depends { name: "SomeLibNeededEverywhere" }
}
Product {
name: “C”
Depends { name: "SomeLibNeededEverywhere" }
}
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Of course it is ugly because you have to maintain the transitive dependencies
manually.
However, if you have cases where a dependency is needed in many places, you can
create custom products that include it.
For example:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
// qbs/imports/MyBaseApplication.qbs
CppApplication {
Depends { name: "SomeLibNeededEverywhere" }
}
// in other .qbs files use MyBaseApplication instead of CppApplication
MyBaseApplication {
}
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
See also this thread on the mailing list:
https://lists.qt-project.org/pipermail/qbs/2019-July/002477.html
and the follow up:
https://lists.qt-project.org/pipermail/qbs/2019-August/002544.html
Kind regards
Jochen Ulrich
> Von: Qbs im Auftrag von Карелин Павел
>
> Datum: Dienstag, 30. Juni 2020 um 09:45
> An: "qbs@qt-project.org"
> Betreff: [Qbs] QBS script parsing speed
>
> Hello.
>
> Now I'm trying to write a QBS build script for a fairly large project (QGIS).
> After making every change to the build script - the project tree is rebuilt
> and QtCreator freezes for 10-15 seconds.
> It seems that 10-15 is not so much, but since I have to make a lot of changes
> in the script, in the aggregate the slowdown turns out to be quite
> significant.
> I suppose I was not the only one who faced a similar problem on large
> projects. I would like to know if any measures are being planned to increase
> the speed of re-parsing a project?
> I am using QtCreator 4.11.2 (QBS 1.15.1)
>
>
> --
> BR, Pavel Karelin
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] Undocumented SubProject.condition property
Hi! We found that there is an undocumented `condition` property on SubProject items. It seems to have the same effect as setting the `condition` property inside the Properties block. However, I find it more readable to have the condition on the SubProject instead of inside the Properties block. So the question is: what's the state of this undocumented property? Should it be made official and be documented or is it deprecated and will possibly be removed? Best Jochen ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] building android aab package help
Hi Raphael!
What doesn’t work as expected? Is there any error message or what output is
missing?
> As a fall back solution I can create a new AndroidAab Product that will
> depend on the android application and implement all rules using
> inputsFromDependencies property.
And this works? You already tried this?
Best
Jochen
Von: Qbs im Auftrag von Raphael Cotty
Datum: Dienstag, 14. April 2020 um 21:27
An: "qbs@qt-project.org"
Betreff: [Qbs] building android aab package help
Hi all,
I am struggling to find a way to build the aab package (non runnable package
required by google store) on the android platform.
For this platform the default qbs product type is changed from application to
android.apk (runnable package).
What I am trying to achieve is allowing the user to just set a property in his
project to enable the build of the aab package:
QtQuiApplication {
name: "myApp"
buildAab: true
...
}
Building an aab is similar to building apk. They both take the same inputs
(including java files) and generate a java file (R.java) but in a different way.
I first tried to add the android.aab type to the product type property in order
to build both types.
But I can't find a way to redirect all java files + the R.java apk to the next
apk rule and all the java files + R.java aab to the next aab rule (without
changing the java module).
It looks like I need to multiplex over the product type...
This simple project summaries the issue (assuming product type multiplexing
exists):
Project {
Product {
multiplexByType: ["android.apk", "android.aab"]
name: "android"
files: [
"a.java",
"b.java"
]
Group {
files: "AndroidManifest.xml"
fileTags: "android.manifest_final"
}
FileTagger {
patterns: "*.java"
fileTags: ["java.java"]
}
// Generate the R.java in a different way according to the product type
Rule {
inputs: "android.manifest_final"
Artifact {
filePath: FileInfo.joinPaths(product.buildDirectory, "R.java")
fileTags: ["java.java"]
}
prepare: {
var cmd = new JavaScriptCommand();
cmd.description = "generating R.java";
cmd.sourceCode = function() {
var readFile = TextFile(input.filePath, TextFile.ReadOnly);
var writeFile = TextFile(output.filePath,
TextFile.WriteOnly)
writeFile.write(readFile.readAll());
if (product.type === "android.apk")
writeFile.write("This is the R.java for apk");
else
writeFile.write("This is the R.java for aab");
writeFile.close();
};
return [cmd];
}
}
// This rule can't be changed as it comes from the java module
Rule {
multiplex: true
inputs: ["java.java"]
outputFileTags: ["java.class"]
outputArtifacts: {
var artifacts = [];
for (var i = 0; i < inputs["java.java"].length; ++i) {
artifacts.push({
fileTags: "java.class",
filePath:
FileInfo.joinPaths(product.buildDirectory,
inputs["java.java"][i].baseName + ".class")});
}
return artifacts;
}
prepare: {
var cmd = new JavaScriptCommand();
cmd.description = "compiling java files";
cmd.sourceCode = function() {
for (var i = 0; i < inputs["java.java"].length; ++i) {
File.copy(inputs["java.java"][i].filePath,
outputs["java.class"][i].filePath);
}
};
return [cmd];
}
}
// Let's gather all compiled java classes and generate the classes.dex
// If running in the apk context then we have all project java classes
and the
// R.java generated in the apk context
// If running in the aab context then we have all project java classes
and the
// R.java generated in the aab context
Rule {
multiplex: true
inputs: ["java.class"]
Artifact {
filePath: "classes.dex"
fileTags: ["android.dex"]
}
prepare: {
var cmd = new JavaScriptCommand();
cmd.description = "generating classes.dex";
cmd.sourceCode = function() {
var writeFile = TextFile(output.filePath,
TextFile.WriteOnly)
for (var i = 0; i <
Re: [Qbs] Depending on a library that is both shared and static
Hi Uwe!
I would probably create two products: one for the static library and one for
the dynamic library and I would make the dynamic library depend on the static
library:
StaticLibrary {
name: "mylibrary-static"
targetName: "mylibrary"
// ...
}
DynamicLibrary {
name: "mylibrary-dynamic"
targetName: "mylibrary"
Depends { name: "mylibrary-static" }
// ...
}
Note that it is *not* necessary to list the source files inside the
DynamicLibrary again unless they should be compiled differently (different
preprocessor defines or similar).
So this will even reduce compile time because the code is compiled only once.
Best
Jochen
Am 20.02.20, 09:26 schrieb "Qbs im Auftrag von Uwe Salomon"
:
Hello,
I've got a question regarding better control of the "Depends" item when
pulling a library that is built both shared and static.
For library projects that are to be packaged for Debian or Ubuntu, I find it
useful to set up the library's Product like this:
DynamicLibrary {
targetName: "mylibrary"
type: ["dynamiclibrary", "staticlibrary"]
//...
Group {
fileTagsFilter: ["dynamiclibrary", "dynamiclibrary_symlink",
"staticlibrary"]
qbs.install: true
qbs.installdir: ...
This way, both the dynamic and the static library are built and installed
(in the staging directory), and can then be put into the Debian package --
the dynamic library into the "libmylibrary1" package, the static library
into the "libmylibrary-dev" package.
Problems arise, however, if one uses a Depends item in a Product in the
same Project for the library. This is necessary in the following cases:
1. a test executable that tests the library
2. some other executable that uses the library
3. another library that uses the library
Usually, one would like to link to the shared library for cases 2 and 3, and
for case 1 the decision depends on whether the test is a true blackbox test
(shared is fine) or a whitebox test (static often necessary).
However, Qbs always links to the static library in these cases. That's
problematic for several reasons.
Do you have any idea how I could control which version of the library is
being pulled into the consuming Product?
Regards,
Uwe
___
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
Re: [Qbs] Interfacing Qbs to Conan
> It would be great if Qbs 1.16 could offer a complete Conan story. We have
> roughly a month until feature freeze.
The ticket(s) I will create are not a requirement for the Conan ModuleProvider
we implemented. So we should not have a problem with this deadline.
The things from the ticket(s) would just allow a simpler/better implementation
of the ModuleProvider and improve its usability.
> It might be beneficial if module providers [...]
Yeah. Those three things would really be helpful.
> I do not think they should have direct access to probes/properties defined in
> the project/product by the user because this would be an "invisible"
> dependency. That means: A provider should not rely on
> project.mycustomProperty.
Okay. That's true. And if the other three things would be possible, it would be
unnecessary to have access to the probes/properties defined in the
project/product.
> Are you aware that module providers operate on product level? You can
> (currently) configure them in the profile and in the product.
Yeah but that's not correct for the Conan ModuleProvider and probably also for
other ModuleProviders. What they need are properties on *project* level.
They should not be configured in a profile because they are specific to a
project. And you don't want to repeat them for every product in the project.
> We could also add the capability to "configure" the fallback provider via the
> Depends item [...]
I also thought about this. However, I would call the property simply
"providers" instead of "fallbackProviders":
Depends {
name: "mylib"
providers: [
"conan",
"pkgConfig"
]
}
>https://codereview.qt-project.org/c/qbs/qbs/+/288927 achieves automatic
> probe re-execution by assigning the modification time stamp of the conanfile
> to a property of the probe.
Yeah. Something like this. Except for ModuleProviders.
>An --force-module-generator-execution command line flag might be worth to
> add to qbs resolve.
I would call it --force-module-provider-execution to make it clear that its
related to the ModuleProviders.
So to summarize: we have the following new requirements regarding
ModuleProviders:
1. ModuleProviders should be able to define their own probes.
2. ModuleProviders should be able to define a logic to "invalidate" their
generated modules (force regeneration of the modules).
3. ModuleProviders should be able to access the project and product they live
in.
4. Projects should be able to configure ModuleProviders like it is possible in
products.
5. Depends items should be able to define which ModuleProviders to use. Doing
this invokes the ModuleProvider like a fallback ModuleProvider (meaning it gets
the complete "name" of the Depends item).
6. qbs resolve should provide a command line flag
--force-module-provider-execution to force regeneration of modules by
ModuleProviders.
Should I create one or multiple tickets for these requirements?
To me it sounds like 1, 3 and 4 might be related while the others are rather
independent.
Best
Jochen
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Interfacing Qbs to Conan
Hi Richard!
> I hope this gives you some ideas how to move forward
Thanks Richard! We really appreciate your help!
> There might be different solutions to this, but what I think would be simple
> and straight forward
Basically, we are doing it the way you described.
However, we decided not to make a conan module which the generated modules
depend on because we expect that this would lead to multiple invokations of
`conan install` (one for each generated module) which we want to avoid.
So we decided to have a project-level probe instead which detects the conan
executable and the conanfile and runs `conan install`.
This way, one can also easily define the path to the conanfile inside the Qbs
files.
> I would be more than happy to discuss any issues appearing on the way.
Yeah. While working on the Conan ModuleProvider, we encountered a few
obstactles. Luckily, it seems we are able to work around them.
I list these obstacles here along with the workarounds we are currently
implementing so we can discuss them.
I would then create a feature request ticket to extend the ModuleProvider
accordingly.
So the following things might be helpful when writing a ModuleProvider:
1.) Access to (project-level) probes
It is quite likely that a ModuleProvider needs some external tools or files and
those should be detected using probes.
In our case, we need to detect the conan executable and the conanfile(s).
Our workaround is to let the project-level probe execute `conan install` so the
ModuleProvider does not need to know the location of the conan executable and
the conanfile(s). This then produces a conanbuildinfo.json which the probe
places in a defined location inside the build directory so that the
ModuleProvider is able to find it.
2.) Access to the project the ModuleProvider is running in
A ModuleProvider might need or save some files in the buildDirectory. So access
to the project.buildDirectory and project.sourceDirectory would be helpful.
In our case, we need to locate the conanbuildinfo.json in the buildDirectory.
Enhancement 1.) might also solve this. However, in our project, we might end up
with several conanbuildinfo.json files (hierarchy of projects) and therefore,
access to project.name to differentiate the files might be helpful.
Our workaround to get the buildDirectory is to assume that the outputBaseDir of
the ModuleProvider is inside the build directory. So we simply do something
like `var buildDirectory = FileInfo.cleanPath( outputBaseDir + '/../..' )`.
For the multiple conanbuildinfo.json files issue, we simply take all of them
inside a defined directory.
3.) Access to the full name of the Depends items for which the ModuleProvider
was called
This works for the fallback ModuleProvider AFAIK. However, at the moment there
can be only one fallback ModuleProvider AFAIK. So it would not be easily
possible for a project to use both pkgConfig and Conan, right?
Allowing access to the full name of the Depends item in a regular
ModuelProvider when evaluating the relativeSearchPaths property would allow
writing something like `Depends { name: "conan.somePackage" }` which would
invoke the conan ModuleProvider which would then generate the Module for
"somePackage".
Our workaround is to generate Modules for all dependencies from the conanfile,
no matter if they are used as Depends items in Qbs or not.
So this is not a real issue in our case but it limits ModuleProviders which do
not have something like the conanfile but only rely on the name of the
dependency.
4.) Mechanism to force execution of the ModuleProvider
Since ModuleProvider generate modules on a dynamic basis, it is not unlikely
that the environment changes and the ModuleProvider needs to re-run. At the
moment, this can be forced with the --force-probe-execution command line
parameter. However, it would be nice if Qbs could detects this automatically.
I'm not sure how this could be realized. Maybe a property on the ModuleProvider
that, when it evaluates to `true`, forces re-execution of the ModuleProvider?
In our case, we would like to re-run the ModuleProvider when the conanfile (or
conanbuildinfo.json) has changed.
Our workaround is that we have to call qbs with --force-probe-execution
manually when the conanfile has changed.
So would those enhancements make sense?
Best regards
Jochen
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Error after running tests
Hi!
The error is not related to installing.
It's a bit unfortunate that there is no "Installation done" message. That's why
it looks like the error is happening during installation.
The error says "ERROR: Cannot run:" because you are trying to `qbs run` but the
"check" product is not an application but the AutotestRunner.
The AutotestRunner runs the tests during the build step. That's a bit
confusing...
So instead of
$ qbs run -p check
you should do
$ qbs build -p check
Kind regards
Jochen Ulrich
Am 14.01.20, 22:18 schrieb "Qbs im Auftrag von Alberto Mardegan"
:
Hi there!
I'm using the AutotestRunner to run the unit tests in my project [1].
The tests run successfully, but then QBS tries to install them (why?)
and fails:
===
$ qbs project.enableCoverage:true project.buildTests:true
[...]
$ qbs run -p check
Restoring build graph from disk
Building for configuration default
Clearing coverage data [coverage-clean]
Running test path-test [check]
/home/mardy/src/git/mappero/default/path-test.6e444deb/path-test
* Start testing of Mappero::PathTest *
Config: Using QtTest library 5.12.4, Qt 5.12.4
(x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 5.3.1
20160406 (Red Hat 5.3.1-6))
PASS : Mappero::PathTest::initTestCase()
PASS : Mappero::PathTest::loadGpx()
PASS : Mappero::PathTest::loadKml()
PASS : Mappero::PathTest::saveGpx()
PASS : Mappero::PathTest::positionAt()
PASS : Mappero::PathTest::cleanupTestCase()
Totals: 6 passed, 0 failed, 0 skipped, 0 blacklisted, 54ms
* Finished testing of Mappero::PathTest *
Build done for configuration default.
Installing
ERROR: Cannot run: Product 'check' is not an application.
===
("check" is the name of the AutotestRunner item)
It's been a while since I ran the unit tests on this project, but I
don't remember having seen this before.
Is there a way to suppress the installation (or at least to get rid of
the error)?
Ciao,
Alberto
[1]: https://gitlab.com/mardy/mappero
___
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
Re: [Qbs] Improving qbs resolve performance
I want to follow up on this topic: I created scripts to generate a Qbs project of a specified size. Then, I created a few projects and measured the resolve time. Bottom line: Exporting dependencies significantly slows down the resolving. It is better to explicitly depend on the needed modules instead of having another module export the dependency. It’s a trade-off between having to write more “Depends” items vs. slower resolving. The scripts and the results can be found here: https://gist.github.com/j-ulrich/35f345007809c77403a8ee88f4d9db11 Best Jochen ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
