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
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
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:
> 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)
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 Auftr
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
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.
> 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
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
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
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.
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
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 Q
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
<<<<<<<<<<<<<<<<<<<
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:
>>>>
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
ject.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
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:
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
> 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 Ulr
>> 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: [
21 matches
Mail list logo
