Re: [Qbs] Crash after build

[Maximilian Hrabowski]

Hi,
i also encounter a crash with qbs 2.3 during project resolving that is 
difficult to grasp — i should check it with a debug build.

It happens when the project was resolved by a previous run and then something 
has changed.

I can work around the crash by settings —jobs 1 (or —jobs 4) or some other 
small value.
—jobs 1 always avoids the crash, but most of the time —jobs 2/3/4 also does 
when it crashes reliably when using more.

One the resolve has finished i can stop and start over with all cores. So there 
seems to be some kind of race condition in the resolver?!

So does it help you to
- run resolve first with —jobs 1
- and the build
?
Cheers,
Maxim

From: Qbs  on behalf of Marc Hüskens 

Date: Monday, 15. July 2024 at 18:00
To: qbs@qt-project.org 
Subject: [Qbs] Crash after build
[Sie erhalten nicht häufig E-Mails von marc.huesk...@aucos.de. Weitere 
Informationen, warum dies wichtig ist, finden Sie unter 
https://aka.ms/LearnAboutSenderIdentification ]

Hi,

I am still using Qbs 1.24, because starting with version 2.0 (or so) qbs 
crashes after build.
We have a quite large project with lots of applications and libraries, which 
takes a while to load and build.

Anyhow, version 1.24 and earlier work fine, but version 2.x complete with a 
„qbs has crashed“ message in QtCreator.
This leads to a complete rebuild every time.

I do recall that there was an environment variable or so to enable debug 
logging, but I cannot find any hint to that.

So my question is, what is the best way to debug a crash of qbs?

Kind regards,
Marc Hüskens
___
Qbs mailing list
Qbs@qt-project.org
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.qt-project.org%2Flistinfo%2Fqbs&data=05%7C02%7Chrabowski%40bee360.com%7C3d1294f61eb94c80878808dca4e733b8%7C17a5b20ffd8e44fabfd64fc263f8e0b4%7C0%7C0%7C638566560118192060%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=PO5tsNpKmpUJz2VR474aPa85gPKkd%2F4ysqM8vTZib34%3D&reserved=0
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

[Qbs] Rule to create library symlinks on macos

[Maximilian Hrabowski]

Hi all,

i use qbs on macos to combine arm64 and x86_64 library builds into one 
universal library.  My application compiles and links, but cannot start because 
the install names/lib names used when linking the app are not correct – or – 
basically they are correct but when combining the builds using lipo, no 
corresponding symlinks are created. So there is a symlink missing thus the app 
fails to load the library at start up.

E.g.


  *   Library file name of prebuild binaries is “libfmt.11.0.0.dylib”, there 
are symlinks “libfmt.dylib” and “libfmt.11.dylib” in the original single arch 
builds
  *   Qbs created the universal lib “libfmt.11.0.0.dylib” and a symlink 
“libfmt.dylib” but NO symlink “libfmt.11.dylib”
  *   The app is linked using the intall-name “libfmt.11.dylib”


  *   App cannot start because “libfmt11.dylib” cannot be found

I could now manually create the missing link on deployment, but…

Is there is a way to explicitly create the missing symlink with qbs?

I created a bug report to illustrate the problem: 
https://bugreports.qt.io/browse/QBS-1797

Cheers,
Maxim

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

[Qbs] Passing data from current project to module-provider

[Maximilian Hrabowski]

Hi all,

Is there a way to pass data from the current project to a module-provider 
(/module-providers/myProvider/provider.qbs)?

When the relativeSearchPaths is evaluated inside the module-provider, it seems 
that nearly  no properties are available. It would be enough to know the 
build-directory or pass in a path.
A work-around vould be to use outputBaseDir+”/../../..” but I’m not sure 
whether this is safe or there is a better way. Passing information determined 
at the beginning of a build (e.g. with a Probe) to the module-provider does not 
seem to be extra-ordinary to me.

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

[Qbs] Using ES6 templates string in qbs files

[Maximilian Hrabowski]

Hi all,

I thought qbs 2.x switched to latest QJSEngine which support ES7.
While in QML code it is no problem to use template strings `…` , in qbs files I 
get a syntax error, e.g.:

console.log(`the path is ${path}`);

won’t work.

Are my expectations wrong?

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

Re: [Qbs] Qt6 support

[Maximilian Hrabowski]

Thanks, indeed the problems seem to be of different source now, core5compat is 
found. 

The error messages shown in Qt Creator suggested that, but when building on the 
command line there are different problems reported.

> On 7. Dec 2020, at 10:35, Christian Kandeler  wrote:
> 
> On 12/4/20 10:44 AM, Maximilian Hrabowski wrote:
>> Is Qt6 already supported by qbs?If so which version is required? Doing a 
>> naive “Depends { name: “Qt.core5compat” } with abs 1.17 did not work ;)
> 
> In general, everything should work out of the box. All problems observed so 
> far have been on the Qt side, as a fallout of the switch to cmake. They have 
> been/are being fixed. The last time I checked, Windows was broken due to a 
> prl file problem, but Linux should work with the current Qt RC.
> 
> There is no specific support for the core5compat module, nor does there need 
> to be one. If it's there, it will get picked up.
> 
> 
> Christian
> 
> ___
> 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] Qt6 support

[Maximilian Hrabowski]

Him
I require core5compat.

I’ve I installed qbs using home-brew, but my version was 1.16.0 - just upgrade 
to 1.17.0. So the requirement for  core5compat is actually 1.17.1, right?

Best regards,
Maximilian Hrabowski

On 4. Dec 2020, at 14:07, Иван Комиссаров 
mailto:abba...@gmail.com>> wrote:

Did you install this module using the MaintenanceTool? It doesn’t get installed 
by default

Ivan

4 дек. 2020 г., в 10:44, Maximilian Hrabowski 
mailto:hrabow...@clausmark.com>> написал(а):

Hi all,

Is Qt6 already supported by qbs?If so which version is required? Doing a naive 
“Depends { name: “Qt.core5compat” } with abs 1.17 did not work ;)

Best regards,
Maximilian Hrabowski

___
Qbs mailing list
Qbs@qt-project.org<mailto: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

[Qbs] Qt6 support

[Maximilian Hrabowski]

Hi all,

Is Qt6 already supported by qbs?If so which version is required? Doing a naive 
“Depends { name: “Qt.core5compat” } with abs 1.17 did not work ;)

Best regards,
Maximilian Hrabowski

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

[Qbs] Set cpp properties for generated cpp files (moc) does not seem to work

[Maximilian Hrabowski]

Hi all,

we have quite a strict warning policy so all warnings are treated as errors in 
our code. This creates problems when including third-party code that produces 
warnings, so usually those files are put in a special group and 
warningsAreErrors is turned off:

Group {
…
cpp.treatWarningsAsErrors: false
}

This usually works quite well. But now i’ve got the problem that i need to 
disable this for cpp files generated by moc. I tried the following approach but 
it does not seem to work:

Group {
fileTagsFilter: [“moc_cpp"]
cpp.treatWarningsAsErrors: false
}

is this supposed to work and probably a bug (maybe related to 
https://bugreports.qt.io/browse/QBS-1030) or are my expectations wrong…

Cheers,
Maximilian



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

Re: [Qbs] Passing settings to qbs generators using the command line

[Maximilian Hrabowski]

I’ll have a look, thanks!

> On 19. Nov 2019, at 10:43, Christian Kandeler  
> wrote:
> 
> On Tue, 19 Nov 2019 08:07:22 +
> Maximilian Hrabowski  wrote:
> 
>> Is there a way to pass settings to qbs generators using the command line?
> 
> Not yet, because no one has needed it so far.
> This feature can be easily added, though: Just extend the GenerateCommand 
> class to behave like RunCommand (using the "--" separator for extra 
> arguments), and pass these additional arguments to 
> ProjectGenerator::generate().
> Wanna give it a go?
> 
> 
> Christian
> ___
> 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

[Qbs] Passing settings to qbs generators using the command line

[Maximilian Hrabowski]

Hi all,

Is there a way to pass settings to qbs generators using the command line?

I’m currently writing a qbs generator to generate a product dependency graph 
using dot/graphviz. Although it was quite straightforward to get some output in 
the first place now I need a way to parameterize the generation. For now i 
basically need to skip certain modules in the process, so configuring inside 
the qbs files does not seem to be a good way. Later i might need to specify 
common settings like colors, fonts and other visual settings that may go into 
the qbs files as those could directly depend on the corresponding 
project/product.

Best regards,
Maxim



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

Re: [Qbs] Improving qbs resolve performance

[Maximilian Hrabowski]

On 11. Jul 2019, at 14:45, Christian Kandeler  wrote:
> 
> On Thu, 11 Jul 2019 12:18:30 +0000
> Maximilian Hrabowski  wrote:
> 
>> I have a fairly large project with a root projects that pulls in several 
>> SubProjects, altogether with unit tests its about 313 qbs files that are 
>> pulled in.
> 
> The number of project files is not all that important by itself. Qt Creator, 
> for instance, has a comparable number, and resolves much faster than your 
> project.

Can you give any guidance what to avoid, i.e. what makes resolving slow if QtC 
is much faster resolved?

> 
>> Let root.qbs be the root qbs file of my project and depend.qbs a subproject 
>> that many other subprojects depend on.
>> 
>> With a single profile and single config I encounter the following duration 
>> for qbs resolve on my macbook pro with 12 logical CPUs:
>> 
>> 1) qbs resolve (clean, new build directory, so includes creating a build 
>> graph):  ~1m 25s
> 
> qbs --log-time might give some hints as to where that time is spent.

Adding —log-time revealed that indeed the ModuleLoader uses up nearly about 70% 
of the total time. 
> 
>> 2) qbs resolve (no changes): ~0.5 s
>> 3) qbs resolve after "touch root.qbs" (restores build graph): ~1m 15 s
>> 4) qbs resolve after “touch depend.qbs” (restores build graph): ~1m 15s
>> 
>> From the durations i would expect that there is some room for improvement. 
>> To me it seems (by looking at 3 and 4) that qbs rebuilds the whole build 
>> graph if it detects any change to any qbs file in the project. 
> 
> Yes, there is no partial re-resolve.
> 
>> If this is the case i wonder how difficult it would be to improve this and 
>> what the right approach would be. Maybe looking at “Depends {}” would be 
>> enough to determine the “dirty path”.
> 
> I suspect this is hopeless. In general, there are too many possible 
> interdependencies for a statement like "if file x has changed, we know what 
> only product y can be affected". At the very least, much more now-temporary 
> data from the resolve stage would have to be stored for such logic to work.
> 
>> Fortunately QtC 4.9.x seems to cache something now since opening a qbs 
>> project will no longer cause a full resolve.
> 
> I don't think anything has changed there recently. qbs re-resolved when it 
> thinks that's necessary, i.e. a project file or a property or the environment 
> has changed.

Well, before some event (I consider QtC update to 4.9.x as this event) opening 
the root project always resulted in about 2 minutes wait time. since then 
opening is always quite fast (~5sec). 

> 
>> Any ideas or maybe even someone looking at that already?
> 
> The only remote possibility that I see is somehow making use of concurrency 
> when resolving, e.g. have one thread per product. It would not be trivial, 
> though, due to inter-product dependencies etc; also, you'd need a dedicated 
> script engine per thread. I don't remember the details, but whenever I though 
> about this topic, I quickly stopped again after examining what we do in the 
> ModuleLoader, which is by far the most expensive stage of project resolving 
> these days, and thus the only one worth optimizing.

Indeed, a quick profiling using Instruments does not show any obvious culprit 
to optimize in ModuleLoader but show 70% of time goes there. 

> (I certainly don't want to to dissuade anyone from trying, it's just that you 
> need to be prepared for a disappointing outcome. For a much lower-hanging 
> fruit in the area of performance improvement, take a look at 
> https://bugreports.qt.io/browse/QBS-1448.)


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

[Qbs] Improving qbs resolve performance

[Maximilian Hrabowski]

Hi all,

I have a fairly large project with a root projects that pulls in several 
SubProjects, altogether with unit tests its about 313 qbs files that are pulled 
in.

Let root.qbs be the root qbs file of my project and depend.qbs a subproject 
that many other subprojects depend on.

With a single profile and single config I encounter the following duration for 
qbs resolve on my macbook pro with 12 logical CPUs:

1) qbs resolve (clean, new build directory, so includes creating a build 
graph):  ~1m 25s
2) qbs resolve (no changes): ~0.5 s
3) qbs resolve after "touch root.qbs" (restores build graph): ~1m 15 s
4) qbs resolve after “touch depend.qbs” (restores build graph): ~1m 15s

From the durations i would expect that there is some room for improvement. To 
me it seems (by looking at 3 and 4) that qbs rebuilds the whole build graph if 
it detects any change to any qbs file in the project. If this is the case i 
wonder how difficult it would be to improve this and what the right approach 
would be. Maybe looking at “Depends {}” would be enough to determine the “dirty 
path”.

Fortunately QtC 4.9.x seems to cache something now since opening a qbs project 
will no longer cause a full resolve.

Any ideas or maybe even someone looking at that already?

Best regards,
Maximilian


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

Re: [Qbs] Install/Depends resolution changed from qbs 1.12.2 to qbs 1.13.0?

[Maximilian Hrabowski]

Sorry, I forgot to mention that this happens on macOs only, windows is fine.

On 16. May 2019, at 11:17, Maximilian Hrabowski 
mailto:hrabow...@clausmark.com>> wrote:

Hi all,

after upgrading to qbs 1.13 our build was broken.

During the build process a generator tool it built that depends on a framework 
which is also build. The generator tool is later used to generate code that 
will be compiled into static libraries (services):

1. build framework “framework"
2. build generator “generator” (Depends on “framework, exports build rules)
3. build services (by running “generator” first)

The generator is installed to the install-root and executed from there.

With qbs 1.12.2 everything runs well, with qbs 1.13.0 the build breaks at 3:

- The generator cannot be executed because the dynamic library “framework” 
cannot be found.
- So it seems “generator” is executed before “framework” is installed to 
install-root

I’m not sure whether this is a regression (maybe introduced by the new 
install/installDir properties) or there is just a flaw in our dependencies.

Any ideas?

Best regards

Maxim
—
Mob: +49 (173) 9168556
E-Mail: hrabow...@clausmark.com<mailto:hrabow...@clausmark.com>

___
Qbs mailing list
Qbs@qt-project.org<mailto: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

[Qbs] Install/Depends resolution changed from qbs 1.12.2 to qbs 1.13.0?

[Maximilian Hrabowski]

Hi all,

after upgrading to qbs 1.13 our build was broken.

During the build process a generator tool it built that depends on a framework 
which is also build. The generator tool is later used to generate code that 
will be compiled into static libraries (services):

1. build framework “framework"
2. build generator “generator” (Depends on “framework, exports build rules)
3. build services (by running “generator” first)

The generator is installed to the install-root and executed from there.

With qbs 1.12.2 everything runs well, with qbs 1.13.0 the build breaks at 3:

- The generator cannot be executed because the dynamic library “framework” 
cannot be found.
- So it seems “generator” is executed before “framework” is installed to 
install-root

I’m not sure whether this is a regression (maybe introduced by the new 
install/installDir properties) or there is just a flaw in our dependencies.

Any ideas?

Best regards

Maxim
—
Mob: +49 (173) 9168556
E-Mail: hrabow...@clausmark.com

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

Re: [Qbs] lupdate/ts-file generation support in qbs

[Maximilian Hrabowski]

Is there already a way to generate a txt file containing a file list of 
[cpp,hpp] tagged files for all product and subproducts in a project? With this 
it would be quite easy to write a rule for lupdate.

Maxim

> On 24. Jan 2019, at 09:02, Christian Kandeler  
> wrote:
> 
> On Thu, 24 Jan 2019 07:08:03 +
> Maximilian Hrabowski  wrote:
> 
>> is there already some support in “Qt.core” to create ts files from cpp 
>> sources using lupdate? I can only find lrelease/qm support in the doc.
> 
> No, because lupdate was tied tightly to qmake project files. However, this 
> has recently changed, so we might be able to make use of it in the future.
> 
> 
> Christian
> ___
> 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

[Qbs] lupdate/ts-file generation support in qbs

[Maximilian Hrabowski]

Hi all,

is there already some support in “Qt.core” to create ts files from cpp sources 
using lupdate? I can only find lrelease/qm support in the doc.

Cheers,

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

Re: [Qbs] qbs command line help vs. documentation on qbs.io needs clarification

[Maximilian Hrabowski]

On 18. Jan 2019, at 17:01, Christian Kandeler 
mailto:christian.kande...@qt.io>> wrote:

On Fri, 18 Jan 2019 15:40:04 +
Maximilian Hrabowski mailto:hrabow...@clausmark.com>> 
wrote:

It seems

qbs config:release profile:xxx

just works. but when i try to build both configurations

qbs config:debug config:release profile:xxx

it fails with errors for configuration "release" (can’t resolve module “cpp”, 
“Qt.core” etc.), whereas

qbs config:release config:debug profile:xxx

fails for “debug”. It seems the second config is not associated with the 
profile.

Are you sure? It should be the other way around. If it's really like you 
described above, then please file a bug report at 
bugreports.qt.io<http://bugreports.qt.io>.

Yes :(

But it seems much more complicated. Just created the ticket. Seems it is 
related to the Qt dependency.

https://bugreports.qt.io/browse/QBS-1425



Christian
___
Qbs mailing list
Qbs@qt-project.org<mailto: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] qbs command line help vs. documentation on qbs.io needs clarification

[Maximilian Hrabowski]

Thanks a lot,

...

On 18. Jan 2019, at 15:06, Christian Kandeler 
mailto:christian.kande...@qt.io>> wrote:

On Fri, 18 Jan 2019 13:35:24 +
Maximilian Hrabowski mailto:hrabow...@clausmark.com>> 
wrote:

Further below the doc says: "The position of the property assignment is 
important. In the example above, the profile property is set for all build 
configurations that come afterwards.”

So my questions are:

- Is profile:xxx a property assignment or something special and should it come 
before the config:xxx parameters of after?

It's a special property for the command line, like "config". Whether or not you 
put it before or after the "config" value makes a difference only when building 
for several configurations at once, as explained in the documentation you 
quoted above.

- What means “debug” (qbs.io<http://qbs.io><http://qbs.io>) compared to 
“config:debug” (cmd help), which is right, which is outdated?

config:debug is right.

For my configuration, it does not work if config:debug comes before the 
profile, but i do not have any default profile set.

You'll need to clarify what you mean by that.

It seems

> qbs config:release profile:xxx

just works. but when i try to build both configurations

> qbs config:debug config:release profile:xxx

it fails with errors for configuration "release" (can’t resolve module “cpp”, 
“Qt.core” etc.), whereas

> qbs config:release config:debug profile:xxx

fails for “debug”. It seems the second config is not associated with the 
profile.

> qbs profile:xxx config:debug config:release

works for me. Maybe the latter does not do what i expect.

Maxim


Christian
___
Qbs mailing list
Qbs@qt-project.org<mailto: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

[Qbs] qbs command line help vs. documentation on qbs.io needs clarification

[Maximilian Hrabowski]

Hi all,

when looking at the command line help of the build command i get:

qbs build [options] [[config:] [:] ...] …
Builds a project in one or more configuration(s).
…
So for me this means i can build my project with:

> qbs config:debug profile:myQtProfile —build-directory ../build


However, when looking at the doc at 
http://doc.qt.io/qbs/building-applications.html i can read:

> qbs build profile:Android debug release

.. so the profile seems to come first but just “debug” seems to be something 
different than “config:debug” and profile:xxx looks like a property assignment 
which should come after the config according to the cmd help...

Further below the doc says: "The position of the property assignment is 
important. In the example above, the profile property is set for all build 
configurations that come afterwards.”

So my questions are:

- Is profile:xxx a property assignment or something special and should it come 
before the config:xxx parameters of after?
- What means “debug” (qbs.io) compared to “config:debug” (cmd 
help), which is right, which is outdated?

For my configuration, it does not work if config:debug comes before the 
profile, but i do not have any default profile set.

Best regards,

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