Re: [Qbs] Heads up: New project resolving implementation

[Ola Røer Thorsen]

That is great news, thank you!

Best regards,
Ola


tor. 20. apr. 2023 kl. 10:18 skrev Christian Kandeler via Qbs <
qbs@qt-project.org>:

> Hi,
>
>
> we have just merged
>
> https://codereview.qt-project.org/c/qbs/qbs/+/459764 into the master
> branch, which improves speed and correctness when loading projects.
>
> You should give it a try if you have projects that take excessively long
> to resolve; chances are that you will see improvements.
>
> We also generally recommend to check your projects with it, as it might
> uncover subtle mistakes in your project files that went unnoticed so far
> due to implementation bugs.
>
> And of course there is as always the possibility that the new code has
> new bugs, in which case we'd appreciate a report at bugreports.qt.io.
>
>
> 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] Issues building for Android

[Ola Røer Thorsen]

tor. 15. okt. 2020 kl. 12:17 skrev Raphael Cotty :

> Hi,
> About the use of QtApplication instead of CppApplication in the wizard:
> I don't think it's a QtCreator issue. It's a qbs regression actually.
> The QtApplication.qbs not only adds a Depends on Qt.Core but it also
> changes the targetName for Android (in multiplex).
> Using the CppApplication.qbs even with a Depends on Qt.Core will fail on
> Android.
>
> Is it possible to move the issue to qbs?
> If not then I'll add one to discuss the different ways to solve it.
>

Hi, I have not got the permissions to change the bug report. I can close it
however, if you make another one for Qbs instead. Let me know and I'll
close it.

Btw I can also confirm that adding Depends { name: "Qt.core" } in
CppApplication didn't work.

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

Re: [Qbs] Issues building for Android

[Ola Røer Thorsen]

ons. 14. okt. 2020 kl. 21:03 skrev Raphael Cotty :

> Hi,
> Just tried the Qt Quick wizard. If you change the CppApplication into
> QtGuiApplication then it works (instead of QtApplication).
>
>
Thanks again everyone. So, my previous build error was eliminated by wiping
the build directory completely and starting from scratch. Maybe something
is not cleaned up properly in the build directory even when doing clean
rebuild (stuff created from the android tools, not the c++ compiler).
Googling the internet for the "duplicate class" problem turned up some
others having that issue that aren't using Qbs, recommending just wiping
all build artifacts.

Starting everything from scratch but with a QtApplication didn't work for
me, I needed to set those two extra properties in the Qbs profile manually.
But then it works! Finally, my app runs on the target Android device.

Summary:
- Clean install of QtCreator letting it set up Android SDK/NDK doesn't
quite work, might need to set the two additional Qbs properties in the kit
manually. In my case:
Android.sdk.buildToolsVersion: 29.0.2
Android.sdk.platform: android-29
- Use QtApplication, not CppApplication. The QtCreator-wizard could need
this change to avoid more confusion. Reported it here:
https://bugreports.qt.io/browse/QTCREATORBUG-24783
- There might be some cleanup-issue in the build artifacts when messing
around like I just did, causing the duplicate class error. Quick fix was to
delete the whole build directory and try again.
- Qt 5.15.x does not work for Android with Qbs yet, so I'll stick with Qt
5.14.

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

Re: [Qbs] Issues building for Android

[Ola Røer Thorsen]

ons. 14. okt. 2020 kl. 19:55 skrev Richard Weickelt :


> Qt Creator is not part of the tests. We run everything with Qbs only on the
> command line in a Docker image.
>
>
Thanks!!

Some progress now: first, if I set these two additional properties in the
Qbs-part of the kit, I get further building:
Android.sdk.buildToolsVersion: 29.0.2
Android.sdk.platform: android-29

These two were empty when checking them for the kit used, so the build part
calling "aidl" failed.

Also, the Qt Creator wizard setting up an empty Qt Quick project for Qbs
creates it with a CppApplication item, depending only on Qt.quick. This
caused a further problem "cannot find application binary". Fixed by using
the QtApplication item instead (just depending on Qt.core does not help).

Now, the build fails because "Some input files use or override a deprecated
API" (I'll paste the build output below...)

Best regards,
Ola



Generating Android Package
  Input file:
/home/olathorsen/src/build-androidtest-Android_Qt_5_14_2_Clang_Multi_Abi-Release/Release_Android__97aac75243e7a13e/androidtest.48600a3e/androiddeployqt.json
  Output directory:
/home/olathorsen/src/build-androidtest-Android_Qt_5_14_2_Clang_Multi_Abi-Release/Release_Android__97aac75243e7a13e/androidtest.48600a3e/deployqt_out/
  Application binary: androidtest
  Android build platform: android-29
  Install to device: No
  -- Skipping
/home/olathorsen/Qt/5.14.2/android/plugins/iconengines/libplugins_iconengines_qsvgicon_arm64-v8a.so.
It has unmet dependencies:
lib/libQt5Svg_arm64-v8a.so,lib/libQt5Widgets_arm64-v8a.so.
  -- Skipping
/home/olathorsen/Qt/5.14.2/android/plugins/imageformats/libplugins_imageformats_qsvg_arm64-v8a.so.
It has unmet dependencies:
lib/libQt5Svg_arm64-v8a.so,lib/libQt5Widgets_arm64-v8a.so.
  -- Skipping
/home/olathorsen/Qt/5.14.2/android/plugins/iconengines/libplugins_iconengines_qsvgicon_x86_64.so.
It has unmet dependencies:
lib/libQt5Svg_x86_64.so,lib/libQt5Widgets_x86_64.so.
  -- Skipping
/home/olathorsen/Qt/5.14.2/android/plugins/imageformats/libplugins_imageformats_qsvg_x86_64.so.
It has unmet dependencies:
lib/libQt5Svg_x86_64.so,lib/libQt5Widgets_x86_64.so.
  -- Skipping
/home/olathorsen/Qt/5.14.2/android/plugins/iconengines/libplugins_iconengines_qsvgicon_armeabi-v7a.so.
It has unmet dependencies:
lib/libQt5Svg_armeabi-v7a.so,lib/libQt5Widgets_armeabi-v7a.so.
  -- Skipping
/home/olathorsen/Qt/5.14.2/android/plugins/imageformats/libplugins_imageformats_qsvg_armeabi-v7a.so.
It has unmet dependencies:
lib/libQt5Svg_armeabi-v7a.so,lib/libQt5Widgets_armeabi-v7a.so.
  -- Skipping
/home/olathorsen/Qt/5.14.2/android/plugins/iconengines/libplugins_iconengines_qsvgicon_x86.so.
It has unmet dependencies: lib/libQt5Svg_x86.so,lib/libQt5Widgets_x86.so.
  -- Skipping
/home/olathorsen/Qt/5.14.2/android/plugins/imageformats/libplugins_imageformats_qsvg_x86.so.
It has unmet dependencies: lib/libQt5Svg_x86.so,lib/libQt5Widgets_x86.so.
processing androiddeployqt outout [androidtest]
Stripping unneeded symbols from deployed qt libraries [androidtest]
processing resources [androidtest]
Error: Process '/usr/lib/jvm/java-8-openjdk-amd64/bin/java' finished with
exit code 1. The standard output was:
[
]
 The standard error output was:
/home/olathorsen/src/build-androidtest-Android_Qt_5_14_2_Clang_Multi_Abi-Release/Release_Android__97aac75243e7a13e/androidtest.48600a3e/gen/com/example/androidtest/BuildConfig.java:2:
error: duplicate class: com.example.androidtest.BuildConfig
public final class BuildConfig {
 ^
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 error

The following products could not be built for configuration
Release_Android__97aac75243e7a13e:
androidtest
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Issues building for Android

[Ola Røer Thorsen]

man. 12. okt. 2020 kl. 20:34 skrev Raphael Cotty :

> Hi,
> Looks like your android profile is not correct.
>

Agreed. (It was set up automatically by QtCreator).


> What do you have for the sdkDir/ndkDir keys?
> Are they pointing to the android sdk/ndk?
>

Android.sdk.sdkDir: /home//Android/Sdk
Android.ndk.ndkDir: /home//Android/Sdk/ndk/21.1.6352462
(these paths exist)

I now also tried to build using Qt 5.14.2, but no change (still problems
starting with not finding the aidl tool).

Seems like something is broken where the kit is set up, as the
Android.sdk.buildToolsVersion is not set.

Is a clean install of Qt, QtCreator + QtCreator setting up the Android
SDK/NDK a part of the CI for Qbs?

If anyone can share a complete and working android profile here, then I can
try to fill in the blanks in the QtCreator kit.

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

Re: [Qbs] Issues building for Android

[Ola Røer Thorsen]

man. 12. okt. 2020 kl. 16:45 skrev Christian Kandeler <
christian.kande...@qt.io>:

> Do you have qbs.architectures set in your project? You could try setting
> it to some permutations of the supported set (as printed by the quoted Qt
> detection code), and see whether they all fail or just e.g. the ARM one.
>

They are set (automatically), the default values are
armv7a,arm64,x86,x86_64. If I try to set the qbs.architectures property
from within the project, then something else goes wrong so Qbs refuses to
build ("module Qt.Quick could not be loaded" etc,). There is no GUI in
QtCreator to set only one or more of the architectures as far as I can see.

Also tried to set

Android.sdk.buildToolsVersion: "29.0.2"

in my project, that brings the build just slightly further,
aidl E 10-12 17:16:49 10007 10007 aidl.cpp:411] cannot open preprocessed
file: /home/olathorsen/Android/Sdk/platforms/framework.aidl
here, the "missing" directory in platforms is called android-29 in the SDK.

This is with using Qt 5.15.2 btw. I'll try 5.14 next to see if there is
anything different there.. Last time I tried building for Android it did
not try to multiplex building for all the architectures at once like this.

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

Re: [Qbs] Issues building for Android

[Ola Røer Thorsen]

man. 12. okt. 2020 kl. 15:49 skrev Christian Kandeler <
christian.kande...@qt.io>:

> Looks like Android.sdk.buildToolsVersion is empty. Please verify. However,
> I think this should have resulted in an error message from the respective
> Probe. Are you sure your project loaded without warnings? What if you set
> "Force Probes" in the build settings?
>
>
Force Probes had no additional effect. So far as I can see the
buildToolsVersion property is "undefined".
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Issues building for Android

[Ola Røer Thorsen]

man. 12. okt. 2020 kl. 15:49 skrev Christian Kandeler <
christian.kande...@qt.io>:

> On Mon, 12 Oct 2020 15:07:14 +0200
> Ola Røer Thorsen  wrote:
>
> > The process '/Android/Sdk/build-tools/aidl' could not be started:
> > execve: No such file or directory.
>
> Looks like Android.sdk.buildToolsVersion is empty. Please verify. However,
> I think this should have resulted in an error message from the respective
> Probe. Are you sure your project loaded without warnings? What if you set
> "Force Probes" in the build settings?
>

Thanks Christian. How do I best verify that the buildToolsVersion is empty?
The "dummy property console print trick?"

Re-starting from scratch, I get this message in the "General Messages" log
in Qt Creator:

---
Performing API discovery ...
Checking for license updates ...
Checking for updated license succeeded (4 licenses fetched)
[qbs] Build graph does not yet exist for configuration
'Debug_Android__fee4c0a9d0119005'. Starting from scratch.
[qbs] Setting up Qt at '/home/olathorsen/Qt/5.15.1/android/bin/qmake'...
[qbs] Qt with multiple abi detected: 'armeabi-v7a,arm64-v8a,x86,x86_64'
[qbs] Configuring abi 'armeabi-v7a'...
[qbs] Configuring abi 'arm64-v8a'...
[qbs] Configuring abi 'x86'...
[qbs] Configuring abi 'x86_64'...
[qbs] Qt was set up successfully.
Compiler feature detection failure!
The command
"/home/olathorsen/Android/Sdk/ndk/21.1.6352462/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++
-x c++ -E -dM -target arm-linux-androideabi -target '' -fPIC -std=c++14 -"
terminated with exit code 1.
error: unknown target triple 'unknown', please use -triple or -arch
---

Again that looks like the sdk version is not set properly.. How do I set it
manually? I guess it normally should be set automatically when the
QtCreator kits are generated.

Best regards,
Ola








>
> 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] Issues building for Android

[Ola Røer Thorsen]

Hi, anyone know the status of building Qt apps for Android using Qbs now?
I've successfully done this before, but now I can't get it to work.

I've got QtCreator 4.13.2 installed, and have set up everything regarding
the Android SDK/NDK from within QtCreator. Everything should be Ok
(QtCreator says "Java Settings are OK", "Android settings are OK. (SDK
Version: 3.1, NDK Version: 21.1.6352462)"; "OpenSSL Settings are OK".)

If I create a new Qt Quick app from the QtCreator wizard, I can
successfully build and deploy on my Android phone if I use either qmake or
cmake. But for Qbs, it now ends with

Processing IMinistroCallback.aidl [androidtest]
Processing IMinistro.aidl [androidtest]
copying Qt resource templates [androidtest]
The process '/Android/Sdk/build-tools/aidl' could not be started:
execve: No such file or directory.

Looking inside the Sdk directory, the aidl binary is indeed not there, but
rather found in the subdirectories 29.0.2 and 28.0.3.

Known issue, new bug? Any hints how to get around this?

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

Re: [Qbs] QtC 4.10.1 missed QBS 1.14.1!!

[Ola Røer Thorsen]

ons. 9. okt. 2019 kl. 09:20 skrev Christian Kandeler <
christian.kande...@qt.io>:

> What is all this talk about 1.14.1? 1.14.0 has not even been released yet.
> We expect it shortly.
>
>
FYI it became somewhat important because of this issue here,
https://bugreports.qt.io/browse/QBS-1492

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

Re: [Qbs] QtC 4.10.1 missed QBS 1.14.1!!

[Ola Røer Thorsen]

ons. 9. okt. 2019 kl. 09:20 skrev Christian Kandeler <
christian.kande...@qt.io>:

>
> What is all this talk about 1.14.1? 1.14.0 has not even been released yet.
> We expect it shortly.
>
>
It was shipped with Qt Creator 4.10.0 and now 4.10.1, it appears to me that
it just has used whatever was at the top in the 1.14 branch. (for both qbs
binaries in Qt Creator 4.10.0 and .1 qbs --version reports 1.14.0.)



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

Re: [Qbs] QtC 4.10.1 missed QBS 1.14.1!!

[Ola Røer Thorsen]

ons. 9. okt. 2019 kl. 09:20 skrev Christian Kandeler <
christian.kande...@qt.io>:

> On Tue, 8 Oct 2019 22:38:49 +0300
> Denis Shienkov  wrote:
>
> > Seems, you are forgot to deliver QBS 1.14.1 with QtC 4.10.1. Right now I
> > see that it use QBS 1.14.0.
>
> What is all this talk about 1.14.1? 1.14.0 has not even been released yet.
> We expect it shortly.
>
>
> 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] QtC 4.10.1 missed QBS 1.14.1!!

[Ola Røer Thorsen]

It looks like at least some fixes were included, as I'm able to build with
Qt 5.13.1 now (which was impossible with Qt Creator 4.10.0). But I've got
no idea exactly which commits were included either. Maybe it's just the
version bump commit that is missing?

Ola


tir. 8. okt. 2019 kl. 21:39 skrev Denis Shienkov :

> Hi guys,
> Seems, you are forgot to deliver QBS 1.14.1 with QtC 4.10.1. Right now I
> see that it use QBS 1.14.0.
>
> How it happens? I was hoping for QBS 1.14.1... All my fixes go to
> /dev/ass:((
>
> BR,
>
> Denis
> ___
> 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] Qbs with Qt 5.13.1 broken

[Ola Røer Thorsen]

Hi all Qbs users, just FYI, it's currently not possible to use Qbs to build
Qt applications with the just recently released Qt 5.13.1.

I made a bug report (where the reason has been found already, see comments)
https://bugreports.qt.io/browse/QBS-1492

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

Re: [Qbs] Who compared build times of Qt Creator with CMake and qbs?

[Ola Røer Thorsen]

tir. 14. mai 2019 kl. 10:12 skrev Vincent Hui :

> We can see Qbs development is active.
> https://github.com/qbs/qbs/commits/master?before=ca4987ae21f3cb30fde699448abc213b37b90214+35
> Therefore I don't think it is dead.
>
>
Sure I agree, however if the mindset elsewhere is that "Qbs is dead", they
won't even look into the Qbs changelogs no matter how active it is.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Who compared build times of Qt Creator with CMake and qbs?

[Ola Røer Thorsen]

tir. 14. mai 2019 kl. 09:45 skrev Vincent Hui :

> Hi,
>
> Qt Creator was ported to CMake
> . It is interesting to
> compare build times of Qt Creator with CMake and Qbs.
>
> Did anyone benchmark qbs against cmake?
>
>
I'd like to know if Qt Creator will phase out Qbs support completely,
seeing the comments and summary in that commit ("Qbs is dead"). Would be
really bad for at least my team, if they did.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

[Qbs] Some dependency scanning/tracking-questions

[Ola Røer Thorsen]

I'm trying to replace a large scons-based build system with Qbs, mainly to
try to improve incremental build times. So far it's looking very promising.
We're curious about how Qbs deals with a couple of things, to be sure
before we might decide to leave scons behind for good.

- How does Qbs keep track of depedencies, like when including c-headers
that include other c-headers etc.?

- Is the compiler used for the scanning of dependencies, or does Qbs scan
everyting itself?

- Is the file timestamps used to check for modified files, or a checksum of
the contents?

- Will/could Qbs be able to scan dependencies in ld linker scripts? We've
got several of those where there are .ld files with "INCLUDE
x.ldscript" inside, and it's important that binaries are linked again
if any of those are modified. If Qbs can't scan these itself, is it
possible to somehow list those files so that the linking can be done again
if any of them are modified?

Cheers,
Ola
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

[Qbs] How to use ">" as argument to cat in the Command item

[Ola Røer Thorsen]

I'm writing a Rule where one of the commands is using cat like this:

cat file1 file2 file3 > finalfile

My qbs code does this:

var cmd = new Command("cat", ["file1","file2","file3",">","finalfile"]);

The command line being used wraps > like '>', which doesn't work:

cat file1 file2 file3 '>' finalfile

Is this a qbs bug? Any way to work around this?

Cheers,
Ola
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Can't find variable when using custom property

[Ola Røer Thorsen]

> Custom properties are collected and made accessible in rules for the
> Product, Project and Modules items.
> For all other items, only the built-in properties are retrieved and acted
> upon according to their documented semantics.
>
>
Right. What's the reasoning why custom properties aren't generally allowed?
I would like an error message from qbs if I create a custom property
somewhere that cannot be used, at least. I'm quite used to writing regular
Qt Quick qml and this is then unexpected.


> > My use-case here is that in another Product I plan to do this:
> > import "myrule.qbs" as MyRule
> > ...
> > MyRule { myProperty: "1" }
> > MyRule { myProperty: "2" }
> > MyRule { myProperty: "3" }
> > MyRule { myProperty: "etc" }
>
> Yes, I can see how that could be useful (see also the TODO item in
> CppModule.qbs). You might want to create a task in our bugtracker.
>

I'll do that. Thanks,

Ola
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

[Qbs] Can't find variable when using custom property

[Ola Røer Thorsen]

I'm trying to do something like this:

import qbs
Rule {
property var myProperty: "test"
...

outputArtifacts: {
console.warn(myProperty);
}
}

qbs can't find "myProperty" in the line trying to print it, saying
ReferenceError: Can't find variable: myProperty

I've tried setting an id to the Rule item and using that, doesn't work. How
can I access properties like this from within the Rule item? This does not
seem to work well in general in qbs, except when defining a property in a
"Product" item.

My use-case here is that in another Product I plan to do this:
import "myrule.qbs" as MyRule
...
MyRule { myProperty: "1" }
MyRule { myProperty: "2" }
MyRule { myProperty: "3" }
MyRule { myProperty: "etc" }

Cheers,
Ola
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] How to pass -march=armv7-a to the g++ linking command line (without -Wl, )

[Ola Røer Thorsen]

Hi all,

thanks for the replies guys. Yes the cpp.driverFlags option did the trick,
I don't know why I didn't see it although "driver" is not the first that
came to my mind while searching. And sorry about the misleading email
title, my head must have been elsewhere.

The toolchain I'm using is what I've been given for this project, there is
unfortunately no "*hf" version of the compilers available. It's origin is
openembedded (yocto) I think.

Cheers,
Ola
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

[Qbs] How to pass -march=armv7-a to the g++ linking command line (without -Wl, )

[Ola Røer Thorsen]

I've got a product running on Linux arm imx6. It's being cross-compiled on
Linux x86_64. I've got it set up with both qmake and now qbs that hopefully
should replace qmake at some point.

The binary created by qbs fails to run as it's set up to use the wrong
interpreter. I need to pass "-mfloat-abi=hard" to g++ when it's used to
link the application.

The qmake build ends up linking the application with a command line like
this:

arm-fslc-linux-gnueabi-g++
-mfloat-abi=hard
--sysroot=/srv//sysroots/armv7at2hf-neon-fslc-linux-gnueabi
-Wl,--gc-sections
-Wl,-O1
-Wl,-rpath,/opt/qt5.6.3/lib
-o etc etc

Qbs does this:

arm-fslc-linux-gnueabi-g++
-Wl,-rpath,/opt/qt5.6.3/lib,--gc-sections,-O1
--sysroot=/srv/X/sysroots/armv7at2hf-neon-fslc-linux-gnueabi
-L/srv/XXX/sysroots/armv7at2hf-neon-fslc-linux-gnueabi/opt/qt5.6.3/lib
-march=armv7-a
-o etc etc

I'm struggling to find the property or similar in the cpp module that adds
the "-mfloat-abi=hard"-option to g++ when used for linking.

Adding "-mfloat-abi=hard" to cpp.linkerFlags does not work as the option
should not be wrapped with "-Wl,".

Adding -"mfloat-abi=hard" to cpp.commonCompilerFlags is necessary for the
compiling but does not work for the linking.

So, how do I make qbs link using "g++ --mfloat-abi=hard"?

Best regards,
Ola
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] "qbs setup-qt" and Qt built for cross-compilation

[Ola Røer Thorsen]

Hi, thanks for the reply.

2018-01-04 12:00 GMT+01:00 Christian Kandeler :

>
> > When using cross-compilation, the host tools such as qmake are separated
> > from the installed Qt headers and libraries that are installed into the
> > target device's sysroot.
> >
> > /hostqt contains the host tools
> > /targetsysroot is the root of the target sysroot, in my case i've got Qt
> > installed in
> > /targetsysroot/opt/qt
> >
> > I'll have to build from a build server as well, and now I tried running
> qbs
> > from the command line, setting up the qt version I'm using using "qbs
> > setup-qt". I got some warnings from it, is this a bug or can it be
> ignored?
>
> Depends. It means that qbs modules for these Qt modules are not created,
> so you will not be able to do this in your products:
>
> Depends { name: "Qt.bootstrap" }
> Depends { name: "Qt.qmldevtools" }
>
> The first one you should never need to do. I don't know what the
> qmldevtools library is for.
>
>
Right. I'm not a Qt developer so I do not know either. Qbs just seems to
expect them.


> > Seems like setup-qt is expecting to find the Qt libraries in the path
> > relative to where qmake is installed.
>
> What makes you think that? The output you quoted does not suggest it.
> The libraries, along with their prl files, are looked up in the value
> qmake -query gives you for
> QT_INSTALL_LIBS (more or less, the real code takes care of some special
> cases). The list of libraries should correspond to a subset of the files in
> mkspecs/modules/qt_lib*.pri.
>
>
Sorry this came ut wrong. I should probably have written "qbs should rather
expect to find them at /../lib".

For the Qt versions normally installed by the Qt installer (Qt for x86_64)
into , all these libraries are installed in /lib, and
you'll find qmake in /bin. libQt5Bootstrap and libQt5QmlDevTools
are found together with the rest of the Qt libraries.

When doing cross compilation however, the two mentioned libraries are still
built for the host computer and installed in the host's lib directory,
where all the other libraries built for the target device (here, arm imx6)
are installed in the target sysroot qt/lib directory. This is my
observation, I don't know why or what these are used for.



> > qbs setup-qt /hostqt/bin/qmake crossprofile
> >
> > gives
> >
> > Creating profile 'crossprofile'.
> > Skipping prl file '/targetsysroot/opt/qt/lib/libQt5QmlDevTools.prl',
> > because it cannot be opened (No such file or directory).
> > Skipping prl file '/targetsysroot/opt/qt/lib/libQt5Bootstrap.prl',
> because
> > it cannot be opened (No such file or directory).
>
> Only for these two files?
>

Yes.


> > The files that qbs is looking for here are not in the target rootfs, but
> > rather in
> >
> > /hostqt/lib
>
> These are probably for the host version of the respective library. Look
> for the associated .a files in the same directory and check their
> architecture. It should be x64 or whatever your host machine is.
> I suppose the prl files in the sysroot are simply missing, for reasons I
> don't know. Do the following files exist?
> /targetsysroot/opt/qt/lib/libQt5QmlDevTools.a
> /targetsysroot/opt/qt/lib/libQt5Bootstrap.a
>


The files are built for the host machine (x86_64) and are only installed in
the host lib directory. We have .a, .la and .prl-files.

They do not exist in the target sysroot/opt/qt/lib.


> > Would qbs have been able to figure out the toolchain if the files were
> > found properly?
>
> No, you need to run qbs-setup-toolchains beforehand for your target
> compiler (or afterwards and set the baseProfile manually). Note that
> setup-qt does not extract compiler flags from mkspecs, so you might need to
> fine-tune the toolchain profile afterwards if the respective mkspec
> contains custom flags for that target (you did not seem to have problems
> building with Creator, so the defaults seem to be more or less ok, but
> there might be subtle differences).
>
>
Right. I have set the compiler flags in my own module anyway so I guess
that's why it went well.


> Building using this qmake binary creates proper makefiles
> > for cross compilation without any further configuration necessary, so the
> > information IS there somewhere.
>
> I don't really know what qmake does with prl files, if anything.
>

With the specific qmake binary I get when building Qt for cross
compilation, I run

qmake myproject.pro && make

and it will use the correct compiler (the cross-compiler also used to build
Qt), the correct Qt version and all the correct compiler flags and build my
project for the target device.

Doing the same with qbs requires some more work. I've got ~15 colleagues as
well as some build servers that all need to build this project without
really knowing much about qbs, so I'll make a script that sets up qbs
properly for them.

Would be nice if qbs could extract also this information from the qmake
binary that is used to identify the qt version, as the information is there
somewhere (but 

[Qbs] "qbs setup-qt" and Qt built for cross-compilation

[Ola Røer Thorsen]

I'm building an application on a linux host computer for a target
imx6-based device. I built the Qt version myself configured for
cross-compilation. So far I've only used qbs via QtCreator and the kits
configured there, and this works fine.

When using cross-compilation, the host tools such as qmake are separated
from the installed Qt headers and libraries that are installed into the
target device's sysroot.

/hostqt contains the host tools
/targetsysroot is the root of the target sysroot, in my case i've got Qt
installed in
/targetsysroot/opt/qt

I'll have to build from a build server as well, and now I tried running qbs
from the command line, setting up the qt version I'm using using "qbs
setup-qt". I got some warnings from it, is this a bug or can it be ignored?
Seems like setup-qt is expecting to find the Qt libraries in the path
relative to where qmake is installed.

qbs setup-qt /hostqt/bin/qmake crossprofile

gives

Creating profile 'crossprofile'.
Skipping prl file '/targetsysroot/opt/qt/lib/libQt5QmlDevTools.prl',
because it cannot be opened (No such file or directory).
Skipping prl file '/targetsysroot/opt/qt/lib/libQt5Bootstrap.prl', because
it cannot be opened (No such file or directory).
WARNING: You need to set up toolchain information before you can use this
Qt version for building. However, no toolchain profile was found. Either
create one using qbs-setup-toolchains and set it as this profile's base
profile or add the toolchain settings manually to this profile.

The files that qbs is looking for here are not in the target rootfs, but
rather in

/hostqt/lib

Would qbs have been able to figure out the toolchain if the files were
found properly? Building using this qmake binary creates proper makefiles
for cross compilation without any further configuration necessary, so the
information IS there somewhere.

Cheers,
Ola
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] How do I tell qbs to use the nasm assembler when building using QtCreator and a Qt kit?

[Ola Røer Thorsen]

>
>
> > Group {
> > name: "asm-linux-x86_64"
> > condition: qbs.architecture === "x86_64"
> > files: [ ...the .asm files ]
> > cpp.assemblerName: "nasm"
> > }
>
> That's due to an implementation detail in the cpp module: The assembler
> path is read from the product-global instance, not from the per-artifact
> one. We can easily change that, but are you really using different
> assembler binaries within the same product?
>
>
Not at the same time, but I'm building this code for several platforms. It
will be deployed on x86_64 linux and windows, and on arm linux, possibly
also arm android. The arm version of this code is written in assembly that
can be built with the GNU assembler instead of nasm. That's why I wanted to
set the assembler name only in the group that had the condition
"x86_64"-architecture.

Turns out the arm version builds just fine automatically with Qbs as-is as
the file extension on those source code files is ".S" and "as" is the
assembler to use.

This particular static library I'm building here is OpenH264, and it's one
of many static libraries and applications being built in a "Project".


> > I'll have a similar Group item containing assembly code for linux armv5t
> > and yet another one for Windows, that's why I tried setting the
> > cpp.assemblerName inside the group.
>
> Within the same product? What's the final output binary then?
>

The groups are mutually exclusive, only one of them is used at a time,
depending on if I build for windows, x86_64 linux or embedded linux on arm.


>
> > Setting cpp.assemblerName outside the Group item makes qbs run nasm, but
> > then it's using some options tailored for "as" (I guess) that won't work
> > with nasm:
> > nasm: error: unrecognised option `--64'
> > type `nasm -h' for help
>
> Oh, they didn't bother to make their CLI GNU-compatible? That means it's
> not just a drop-in replacement, but something we need to support
> explicitly. Can you create a task for that at bugreports.qt.io? Ideally
> with some more information about this assembler.
>
>
No I don't think they're aiming for GNU-compatible CLI with nasm. Not even
the source code is compatible (different syntax - nasm uses the intel
syntax whereas gnu uses AT&T). https://en.wikipedia.
org/wiki/Netwide_Assembler

I'll create a task with more information.


> > At this point I'm probably better of writing my own Rule item to process
> > each of the .asm files using nasm, to have full control? (output
> artifacts
> > tagged with "obj"?)
>
> Yes, I suppose so. It's not rocket science. You need to:
> - tag your assembler files as "nasm" or something like that
> - write a Rule that
>   - takes "nasm" as input
>   - creates an Artifact with file tag "obj"
>   - creates a Command calling the nasmn binary
> Maybe you could provide your rule as a reference implementation in the bug
> report.
>
>
Yeah I tried that yesterday and it works very well (thanks to your help
with my previous code generator problem I'm starting to get the hang of it):

Rule {
inputs: ["nasm"]
outputFileTags: ["obj"]
Artifact {
filePath: input.fileName + ".o"
fileTags: ["obj"]
}
prepare: {
var args = ["-I" + product.sourceDirectory +
"/codec/common/x86/",
"-DUNIX64",
"-o", product.buildDirectory + "/" +
input.fileName + ".o",
input.filePath,
];
var cmd = new Command("/usr/bin/nasm", args);
cmd.description = "assembling (nasm) " + input.fileName;
return [cmd];
}
}


> Alternatively, it might even suffice to do this:
> cpp.targetAssemblerFlags: [] // Or put nasm-specific stuff in here, if
> necessary
>
>
No that still kept all the regular includepaths and options, didn't work.
But the Rule solution works just fine.

Thanks,
Ola
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] How do I tell qbs to use the nasm assembler when building using QtCreator and a Qt kit?

[Ola Røer Thorsen]

2017-12-14 18:02 GMT+01:00 Christian Kandeler :

> On Thu, 14 Dec 2017 17:46:56 +0100
> Ola Røer Thorsen  wrote:
>
> > It's running when I tag the files with "asm", but using the assembler
> "as"
> > instead of "nasm". Any way to override that here for this particular
> group
> > of files? The source files are not compatible with "as".
>
> You need to set cpp.assemblerName, either in the profile or in your
> product(s).
>
>
Right. I had only tried setting it inside the Group item, but that didn't
have any effect. I need another Properties item instead to conditionally
set the cpp.assemblerName then?

Group {
name: "asm-linux-x86_64"
condition: qbs.architecture === "x86_64"
files: [ ...the .asm files ]
cpp.assemblerName: "nasm"
}

I'll have a similar Group item containing assembly code for linux armv5t
and yet another one for Windows, that's why I tried setting the
cpp.assemblerName inside the group.

Setting cpp.assemblerName outside the Group item makes qbs run nasm, but
then it's using some options tailored for "as" (I guess) that won't work
with nasm:
nasm: error: unrecognised option `--64'
type `nasm -h' for help

At this point I'm probably better of writing my own Rule item to process
each of the .asm files using nasm, to have full control? (output artifacts
tagged with "obj"?)

Cheers,
Ola
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] How do I tell qbs to use the nasm assembler when building using QtCreator and a Qt kit?

[Ola Røer Thorsen]

2017-12-14 17:27 GMT+01:00 Christian Kandeler :


> Have you tagged them properly? The .asm extension is not auto-tagged on
> Linux; you will need to do that "manually" via a Group or a FileTagger
> item.
> See https://doc.qt.io/qbs/cpp-module.html#relevant-file-tags for the
> assembler-related file tags.
>
>
Ah, I missed that bit with ".asm" being automatically tagget only for MSVC.

It's running when I tag the files with "asm", but using the assembler "as"
instead of "nasm". Any way to override that here for this particular group
of files? The source files are not compatible with "as".

Thanks,
Ola
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

[Qbs] How do I tell qbs to use the nasm assembler when building using QtCreator and a Qt kit?

[Ola Røer Thorsen]

I'm trying to build a project that has some assembly files as well as C++
code. I'm building from QtCreator using the latest Qt 5.10 release kit
(Linux x86_64) on KDE Neon.

The assembly files are added to the files property along with the rest, and
end with .asm. While building qbs seems to just ignore these, and I suspect
it's because the toolchain has no assembler defined.

How can I tell it to use nasm while still using the default kit found in
QtCreator? I've tried setting the cpp.assemblerName and cpp.assemblerPath
properties in my project file but it doesn't seem to have any effect.

Cheers,
Ola
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Need help with setting up a code generator

[Ola Røer Thorsen]

2017-12-13 17:36 GMT+01:00 Christian Kandeler :

>
> That happens automatically if the product has a dependency on the Qt.core
> module.
> Note: The correct file tag for headers is "hpp" (not "h", as I wrote in my
> first reply.)
>
>
Yes using "hpp" fixed it, thanks :-)
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Need help with setting up a code generator

[Ola Røer Thorsen]

Now I've got a new problem related to the code generated library. I've set
up a second version of the library (new templates, basically), where the
code generated is using Qt. So there are a few QObject-based classes etc.

My Rule item that produces the files are setting the fileTags "h" for the
headers and "cpp" for the cpp files being created. Moc is never run on any
of the header files, so there are no additional moc_xxx.cpp files being
created and built. This results in lots of unresolved references in the end
once someone tries to use the library.

How do I make sure moc is run on the autogenerated header files so that the
additional moc code is generated as well?

Thanks,
Ola
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Need help with setting up a code generator

[Ola Røer Thorsen]

Hi Christian, thanks a lot for all your input. The build is very efficient
now. The final solution was a partial "dry run" of the generator tool to
help create the list of artifacts, and the usual full run in the "prepare"
script.

Now that this is working we'll start migrating from qmake to qbs
completely. The QtCreator integration seems to be much more stable now with
the latest release as well.

Best regards,
Ola


2017-12-12 14:29 GMT+01:00 Christian Kandeler :

> On Tue, 12 Dec 2017 14:20:01 +0100
> Ola Røer Thorsen  wrote:
>
> > To run the command inside the outputArtifacts script, I'll use the
> Process
> > object, right?
>
> Yes.
>
> > What is the exact condition for when this script is run? Is it only
> > whenever any of the inputs are modified (or the qbs file I guess)?
>
> Whenever any input has a timestamp newer than any output, or if a property
> accessed in the rule has changed its value since the last run, or if the
> rule source code has changed.
> Modifications to the qbs file only cause rule re-execution if there are
> relevant changes as described above.
>
> > What's the simplest way to define a dummy command in the prepare-script?
>
> var cmd = new JavaScriptCommand();
> cmd.silent = true; // Or cmd.description = "";
> cmd.sourceCode = function() {}
>
>
> Christian
> ___
> Qbs mailing list
> Qbs@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qbs
>
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Need help with setting up a code generator

[Ola Røer Thorsen]

>
>
> > Does this mean I need to know the exact list of files the code generator
> > outputs before it is run? Normally I'd only know that after having run
> the
> > code generator and look into it's output directory.
>
> Then you'll have to run the tool in the outputArtifacts script already.
> Unless the tool has some special "dry-run" option, the actual command could
> then become a dummy.
> The cleaner solution, assuming the tool is under your control, would be to
> give it such an option that prints a suitably formatted list of the outputs
> it would produce.
>
>
I'm not able to change the tool unfortunately. So I'll have to cope even if
it's less than optimal.

- If any of the input files (headers and templates) are modified, the
generator tool must be run, and all the .cpp files it produces must be
rebuilt.
- The number of output files depend on the contents of any of the input
files and is beyond my control
- I can have the generator output text files containing the names of the
generated files.

To run the command inside the outputArtifacts script, I'll use the Process
object, right?

What is the exact condition for when this script is run? Is it only
whenever any of the inputs are modified (or the qbs file I guess)?

What's the simplest way to define a dummy command in the prepare-script?


> var generatorArgs = [
> > product.sourceDirectory + "/api/some*files.h"),
>
> This looks like the wrong thing to do. If you pass some wildcard strings
> instead of actual files, you are circumventing the build system, as it
> cannot do change tracking on the expanded files.
> Instead, you should only pass actual file paths derived from the rule
> inputs.
>
> > Why does the Command object add the '' around strings with * in them, and
> > is there some way to avoid that?
>
> To prevent shell expansion, as the arguments are supposed to go to the
> command as-is. There has not yet been a use case to opt out of this, and I
> don't think yours is a valid one (as explained above).
>
>
Ok fair enough. It's how the generator tool is usually called here, but I
can create a list from the inputs array instead.

Thanks again for all the help!

Ola
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Need help with setting up a code generator

[Ola Røer Thorsen]

Thanks a lot for the help, Christian!

2017-12-11 13:27 GMT+01:00 Christian Kandeler :

> Group {
> name: "header inputs"
> files: ["dir1/*.h"]
> fileTags: ["generator.in.headers"]
> }
> Group {
> name: "template inputs"
> prefix: "dir2/"
> files: ["*.tpl", "*.h", "*.cpp]
> fileTags: ["generator.in.templates"]
> }
>
>
Is there some way to debug-print the contents of these groups as I go along
writing the qbs file?


> Rule {
> // See https://doc.qt.io/qbs/rule-item.html for details.
> multiplex: true // Probably. Not entirely clear from your
> description
>

Yes multiplex seems to be the correct option here.


> inputs: ["generator.in.headers", "generator.in.templates"]
>
> // I assume the number of output files is dynamic and depends on
> // the number and/or contents of the input files.
> outputFileTags: ["h", "cpp"]
> outputArtifacts: {
> // The following two are arrays of artifact objects.
> // Their file paths are available via the filePath property.
> var headerInputs = inputs["generator.in.headers"];
> var templateInputs = inputs["generator.in.templates"];
>
> var outList = [];
> // Do what you need to do here to calculate the output
> // from the input artifacts. The return value is a list of
> // objects with properties filePath and fileTags.
> return outList;
> }
>

Does this mean I need to know the exact list of files the code generator
outputs before it is run? Normally I'd only know that after having run the
code generator and look into it's output directory.

Currently I'm trying to print the contents of headerInputs and
templateInputs like this,

var headerInputs = inputs["generator.in.headers"];
var templateInputs = inputs["generator.in.templates"];

console.warn("headerInputs: " + headerInputs);
console.warn("templateInputs: " + templateInputs);

But the output says "headerInputs: undefined" and "templateInputs:
undefined"


> prepare: {
> var generatorArgs = [];
> // Generate the command-line arguments for the generator tool
> // from the inputs and outputs variables.
> var cmd = new Command("generator", generatorArgs);
> cmd.description = "Running generator";
> return [cmd];
> }
>
>
I've hit some issue with the argument list/array. One of my argument
strings contain a wildcard '*', which casues that string to be wrapped with
'.

var generatorArgs = [
product.sourceDirectory + "/api/some*files.h"),
"-o", product.buildDirectory + "/gen/",
];

The actual command line has the first string wrapped in ' ' because of the
* in the string (wildcards are used for the input to the generator tool).
The code generator doesn't cope with the wrapping in '' (neither will "ls"
or any other command). Here is the resulting command line:

/home/x/bin/generator '/home/xxx/api/some*files.h' -o
/home/xxx/build-xxx-Desktop_Qt_5_10_0_GCC_64bit-Debug/qtc_Desktop_Qt_5_10_0_GCC_64bit_Debug/xxx.3a7a69e5/gen/

Why does the Command object add the '' around strings with * in them, and
is there some way to avoid that?

Best regards,
Ola
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

[Qbs] Need help with setting up a code generator

[Ola Røer Thorsen]

Hi all,

I've got a code generator tool that I'm trying to include in a qbs project.
Currently it's been used in a project using qmake, but I'd like to move on
to qbs.

The code generator (a commandline tool) takes a set of C header files (.h)
in a given directory, and another set of template files (names matching
.tpl, .h and .cpp) in another directory. The output is a set of C++ .h and
.cpp files in an output directory. The number of output files is not the
same as the number of input files.

The resulting .h and .cpp files are to be built into a static library. Also
those header files must be available in the includepath to those needing
it.

Whenever any of the C headers or template files are modified, the code
generator is to be run again.

I'd really appreciate some hints or examples on how this can be done, I'm
currently stuck trying to figure it out.

Best regards,
Ola
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] How do I build using GCC with the "-march=native" option?

[Ola Røer Thorsen]

2017-12-08 11:17 GMT+01:00 Christian Kandeler :

>
> I believe qbs is being overly strict here. There seem to be legitimate
> use cases for -march not covered by dedicated properties. See also
> https://bugreports.qt.io/browse/QBS-1018.
>
>
Ah, I missed that bugreport. Yes I'd agree it's being too strict with
regards to -march. Would be nice if this was fixed.

My use case is to run some computational code as fast as possible on the
host machine, so I'd like the best optimization possible.


>
> As a workaround, you can try the (undocumented) cpp.machineType property.
> It doesn't do anything when using clang, though.
>

I'll try that for now. Thanks!

Best regards,
Ola
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

[Qbs] How do I build using GCC with the "-march=native" option?

[Ola Røer Thorsen]

Hi, I'm trying to build my code with the gcc "-march=native"-option
(x86-64), or any other value there for that matter. Qbs won't let me do
that using

cpp.cxxFlags: [ "-march=native" ]

saying

"warning: The following properties have invalid values:
cpp.cxxFlags: '-target', '-triple', '-arch' and '-march' cannot appear in
flags; set qbs.architecture instead"

Trying

qbs.architecture: "native"

gives

"warning: The following properties have invalid values:
cpp.architecture: 'native' differs from the architecture produced by this
compiler (x86_64)"

How do I fix this?

The -mtune option works but it's not quite what I'm after here.

Best regards,
Ola Røer Thorsen
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] How to set GCC optimization -O3 in releasebuilds?

[Ola Røer Thorsen]

2017-12-01 10:03 GMT+01:00 Christian Kandeler :

>
> In this case, do not set cpp.optimization and use cpp.cxxFlags directly.
> We've decided against allowing more values for cpp.optimization because of
> the difficulties to abstract away the differences between the platforms
> (see https://codereview.qt-project.org/#/c/183884/).
>
>
Makes sense.


> Inheritance is one possibility. Another one is a project-specific module.
> For instance:
>
> // /modules/myprojectsettings/myprojectsettings.qbs
> Module {
> // ...
> Properties {
> condition: qbs.buildVariant === "release" &&
> qbs.toolchain.contains("gcc")
> cpp.cxxFlags: ["-ffast-math", "-O3"]
> }
> }
>
> // someproduct.qbs
> Product {
> // ...
> Depends { name: "myprojectsettings" }
> }
>
>
I quite like the module-solution. I'll have to include the Depends-item in
every product file, right?

Thanks!
Ola
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

[Qbs] How to set GCC optimization -O3 in releasebuilds?

[Ola Røer Thorsen]

Hi all,

what's the recommended way to configure qbs to build C++ code with GCC
using the -O3 optimizer level? I see it's using -O2 for the "fast"
qbs.optimization setting.

My intended workflow is to use -O3 when building from QtCreator in release
mode, while not having to set properties from the command line manually.
This is a somewhat large codebase with several static libraries and
applications (similar in structure as the Qt source tree), currently being
built using qmake.

I might also want to add more default compiler flags "globally"
(-ffast-math etc) at some point. Is it best to create my own
"CustomStaticLibrary" and "CustomApplication"-items and make sure to use
those everywhere instead of the regular ones provided with Qbs?

Best regards,
Ola Røer Thorsen
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Detecting changes in files inside .qrc-files automatically?

[Ola Røer Thorsen]

2017-10-26 20:48 GMT+02:00 Lars Ivar Igesund :

> At least one alternative is to drop the qrc file altogether, put your QML
> files in one or more groups with fileTags: "qt.core.resource_data", and
> (optionally I think) set Qt.core.resource* properties on the product. I
> found this to be much cleaner, and it made it much simpler to put generated
> files into the resources.
>
>
Thanks, that might be useful. Right now I'm still evaluating if it's the
right time to leave qmake or not, so I'm creating a qbs project along with
the old qmake one.

I've updated the bug with my findings so far (
https://bugreports.qt.io/browse/QBS-697). I think this issue should be
re-opened, it looks like some rather subtle bug.

Best regards,
Ola






> Best regards,
> Lars Ivar Igesund
>
> On Thu, Oct 26, 2017 at 8:36 PM Ola Røer Thorsen 
> wrote:
>
>> 2017-10-26 20:31 GMT+02:00 Jake Petroules :
>>
>>> This is supposed to work, but there may be a bug in the qrc scanner
>>> (QBS-697).
>>>
>>> Can you update that issue with an exact set of steps to reproduce the
>>> issue? We tried to reproduce it before but could not.
>>>
>>>
>> Sure. I'll see if I can isolate the issue and upload some code to
>> reproduce it.
>>
>> Best regards,
>> Ola
>>
>>
>> ___
>> Qbs mailing list
>> Qbs@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/qbs
>>
>
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Detecting changes in files inside .qrc-files automatically?

[Ola Røer Thorsen]

2017-10-26 20:31 GMT+02:00 Jake Petroules :

> This is supposed to work, but there may be a bug in the qrc scanner
> (QBS-697).
>
> Can you update that issue with an exact set of steps to reproduce the
> issue? We tried to reproduce it before but could not.
>
>
Sure. I'll see if I can isolate the issue and upload some code to reproduce
it.

Best regards,
Ola
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

[Qbs] Detecting changes in files inside .qrc-files automatically?

[Ola Røer Thorsen]

Hi,

I'm trying out qbs by building an existing Qt Quick-application normally
being built with qmake. I've got my qml files in a qml.qrc file, and have
included this qrc file in the files list in my qbs file.

Everything builds fine from scratch. However it does not seem like qbs is
able to detect if any of the qml files inside the qrc file have changed, so
incremental builds where only qml files were modified do not work.

Do I have to add the qml files to the qbs file as well as to the qrc-file,
or did I miss something else?

Best regards,
Ola
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs