Re: [Qbs] dependency tracking

2020-09-14 Thread Jochen Ulrich
But it will only scan for dependent header files if the product using the code 
generator depends on the `cpp` module and if the `cpp.includePaths` are set up 
correctly, right?
Is this the case?

Best
Jochen


___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs


Re: [Qbs] How to use texttemplate module?

2020-09-10 Thread Jochen Ulrich
> 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?

2020-09-09 Thread Jochen Ulrich
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?

2020-07-31 Thread Jochen Ulrich
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)

2020-07-31 Thread Jochen Ulrich
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?

2020-07-31 Thread Jochen Ulrich
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

2020-07-30 Thread Jochen Ulrich
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

2020-07-29 Thread Jochen Ulrich
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

2020-06-30 Thread Jochen Ulrich
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

2020-06-30 Thread Jochen Ulrich
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

2020-06-30 Thread Jochen Ulrich
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

2020-04-16 Thread Jochen Ulrich
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

2020-04-15 Thread Jochen Ulrich
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

2020-02-20 Thread Jochen Ulrich
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

2020-02-19 Thread Jochen Ulrich
>  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

2020-02-06 Thread Jochen Ulrich
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

2020-01-14 Thread Jochen Ulrich
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] avoid RPATH pointing to Qt installation folder

2019-10-08 Thread Jochen Ulrich
> If I just set
> cpp.rpaths: [ ]
> then I get a linker error wrt. missing ICU libs?

You should try setting the RPATHs to an array of paths which tell the loader 
where to find the libraries.

For example, if your deployment looks like this:

myApp/bin/myApp (the executable)
myApp/lib/libQt5Core.so.5
myApp/lib/...

you might be able to do something like this for the executable:

cpp.rpaths: [ "$ORIGIN/../lib" ]

However, note that you might require different RPATHs during development if you 
want to run the executable without setting up the complete deployment directory 
structure first.

Also note that there are certain security issues with RPATHs. See for example 
https://security.stackexchange.com/a/165762/125269

Kind regards
Jochen Ulrich



___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs


Re: [Qbs] Improving qbs resolve performance

2019-08-30 Thread Jochen Ulrich
> Is it realistic a depth of 9?

I don't know. In our project, we are facing resolve times of 50s and more. But 
I didn't check our dependency tree depth yet. :P
But anyway, it shows the resolve behavior depending on the tree depth.

>  Looking at your timings, it is still not clear where the bunch of the time 
> is spent for the "withLeafExports/9-2-implicit" use case.

Well it goes into "Handling Products". So it is ModuleLoader::handleProduct().
And there, it could be the ModuleMerger. But speculation is dangerous when 
discussing about performance.

I also did another test: re-resolving. That is: just touch the "root.qbs" and 
then resolve again.
And there is one interesting thing: The "Running Probes" step takes nearly the 
same amount of time:

Initial Resolve:
Handling products took 33s, 333ms.
Running Probes took 18s, 67ms.
5355 probes encountered, 5 configure scripts executed, 5348 re-used 
from current run, 0 re-used from earlier run.
Property checking took 412ms.

Re-Resolve:
Handling products took 32s, 798ms.
Running Probes took 17s, 543ms.
5355 probes encountered, 0 configure scripts executed, 0 re-used from 
current run, 5355 re-used from earlier run.
Property checking took 409ms.

I would have expected that "Running Probes" is way faster in the re-resolve 
case.

Best
Jochen
 

Am 30.08.19, 02:07 schrieb "Christian Gagneraud" :

On Fri, 30 Aug 2019 at 11:01, Jochen Ulrich  
wrote:
> I want to follow up on this topic:

I had to check the archives and re-read the whole thread!

> I created scripts to generate a Qbs project of a specified size.
> Then, I created a few projects and measured the resolve time.

Nice one. Maybe it would be nice to automate the data collection, this
way it might be interesting to plot the various measurement versus
tree depth and/or child count and/or product count. Just to see if we
have something linear or logarithmic.
Or maybe that's a job for a C++ benchmark...

> 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.

Good to know, But the Export/Depends has definitely it's use, you
don't need to track nested dependencies.

Random thoughts:
Is it realistic a depth of 9?
Looking at your timings, it is still not clear where the bunch of the
time is spent for the "withLeafExports/9-2-implicit" use case.

Thanks,
Chris


___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs


Re: [Qbs] Improving qbs resolve performance

2019-08-29 Thread Jochen Ulrich
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