Re: [Qbs] Setting properties for all products

[Richard Weickelt]

Hi,

I have a project with multiple sub projects and products and want to move it 
to embedded platforms, and thus I want to set compiler flags like mpcu, 
which should be the same for all products. I know I can do it through the 
QtCreator kit or the command line, but I'd like that to be commited so that 
everyone uses the same flags.


I didn't find a solution, other than defining a module (or product) which 
sets the flags and every product has to depend on. Is there another way? 
Should there be another way? Because adding it to every product is a bit 
tedious and error prone.




You are not the first person requesting this:
https://bugreports.qt.io/browse/QBS-733
https://bugreports.qt.io/browse/QBS-894

The only other proposal was to create a base product which sets the relevant 
flags or loads other modules and let all other products inherit from that. 
That's of coursre not viable if you use predefined extended products like 
CppApplication/QtApplication & friends.


Eventually I settled on having a buildconfig module in my projects that all 
products have to depend on. There is one important advantage with that approach:


Qbs modules can be implemented in several files in a module folder. When 
loading a module with name "buildconfig", Qbs tests the Qbs files in the 
"buildconfig" module folder until it finds one with a matching condition. If 
you are ever going to support multiple target platforms or toolchain types, 
then such a solution would scale well.


That solution breaks as soon as you include other Qbs projects that are not 
under your control as sub-projects.


I still find a global Preference item useful or a default-dependencies 
property in the project item that attaches a module dependency to all products.


Richard

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

Re: [Qbs] Code Generator with shared library dependencies

[Richard Weickelt]

Hi,


So my question would be: Is there a way to run an executable that is a
Product similar to how ‘qbs run’ does it so all dependencies are found?


I don't think there is. You could crawl the dependency tree of your 
application product for shared libraries and unless you find a way to run 
the setupRunEnvironment scripts of those products, you would have to add 
their build directories to the path environment variable before running your 
executable.


I had the same use-case and wanted to extend the rule "Command" towards a 
ProductRunnerCommand in the past that would run the setupRunEnvironment 
scripts, but didn't find the time.

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

Re: [Qbs] passing values for stringList properties on commandline?

[Richard Weickelt]

Hi,

So what is the correct syntax on the commandline for passing values for 
stringList properties?




check this out: 
https://qbs.io/docs/language-introduction/#overriding-property-values-from-the-command-line


Richard

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

Re: [Qbs] ModuleProvider concept

[Richard Weickelt]

On 16.02.2023 11:03, Heiko Nardmann wrote:
*Create* the files in my imagined usecase means for me retrieving necessary 
files from Artifactory - corr. Qbs file and e.g. some static library - and 
provide them so that the project can resolve the dependencies for the build 
graph.


Maybe you could tell us more about your use-case? Artifactory is a storage 
for many things. People use it for instance to distribute Conan packages. 
Are you using some package manager or do you just bundle libraries as zip files?



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

Re: [Qbs] Failed build the project with QBS 1.22.1

[Richard Weickelt]

Hi,


My old version works with replacing 'product' on 'exportingProduct':

    property var exportIncludePaths: [
     "./",
     "./shared",
     ]
     cpp.includePaths: exportIncludePaths

     Export {
     Depends { name: "cpp" }
     cpp.includePaths: exportingProduct.exportIncludePaths
     }


I am not sure whether you have it working or not. Above pattern works on my 
end at least.


According to link https://codereview.qt-project.org/c/qbs/qbs/+/383049 there 
was a change in the definition for variable 'product' inside the section 
'Export'. Maybe then you need to display some message in the log about a 
change in behavior? 


It was a deliberate decision. The topic was first mentioned in:

https://code.qt.io/cgit/qbs/qbs.git/tree/changelogs/changes-1.18.0.md

The "product" variable in Export items was scheduled for removal in the 1.20 
release. The re-introduction of "product", but now as an alias of 
"importingProduct" has been mentioned in:


https://code.qt.io/cgit/qbs/qbs.git/tree/changelogs/changes-1.22.0.md

I now have all the projects at work will fall down. 
People will come to me and say: "Your 'QBS' doesn't work" (I promote the use 
of QBS at my firm).
Can generally prohibit the use of variable 'product' in section 'Export', 
lag behind only 'importingProduct' and 'exportingProduct'? Display a message 
about this in the log.


I am sorry to hear that this change creates inconvenience for you. What 
would you suggest to improve in case we have to do such a breaking change again?


Don't take critics of colleagues personally. You know the problem, you can 
help fixing the problem, everybody will be happy. People complain every day 
and have already forgotten about it the other day.


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

Re: [Qbs] Depending on binary from install-root

[Richard Weickelt]

> Any idea how I can force the rule to depend on the binary in install-
> root/bin?

I think it's cleaner to follow
https://code.qt.io/cgit/qbs/qbs.git/tree/examples/code-generator and use the
transpiler binary in the build directory. That is what your rule really
depends on (explicitlyDependsOnFromDependencies).

If you still need to deploy the transpiler first, then try to add
"installable" to your explicitlyDependsOn. All installed files get that tag
assigned and so your transpiler rule should wait until installation of all
dependency products has completed.

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

[Qbs] 1.19 branch created

[Richard Weickelt]

Hello,

we branched off Qbs 1.19 today. Scheduled release date for
version 1.19.0 is mid of April (together with Qt Creator 4.15) [1]. We
recommend users to try this branch with their projects and report back any
new problems they find. Snapshots of Qt Creator can then be obtained from [2].

Contributors are requested to push bug fixes and small, zero-risk
improvements to this branch, while features continue to go to master.

Patches currently under review can be moved if they are reasonably close to
finished.

Richard

[1] https://wiki.qt.io/Qt_Creator_Releases
[2] http://download.qt.io/snapshots/qtcreator/4.15/
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Qt6 support

[Richard Weickelt]

1.17.1 as in the 1.17 branch is shipped with latest Qt Creator 4.13.x, but we 
haven't made the tag yet nor published any packages. 1.18.0 is around the 
corner and will be released in about 2 weeks.

-Original Message-
From: Maximilian Hrabowski 
To: "Иван Комиссаров" 
Cc: "qbs@qt-project.org" 
Sent: Fri, 04 Dec 2020 15:01
Subject: Re: [Qbs] Qt6 support

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
https://lists.qt-project.org/listinfo/qbs


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

Re: [Qbs] AutotestRunner in QtCreator

[Richard Weickelt]

> 2. Build the AutorestRunner product explicitly. It will not show up under 
> "run".

> That's what I meant, I can not select it as a run target.

> And I don't know how to say "just build product X", if it's not a run target.

In the Projects view, right-click on the autotest-runner product and in the 
context menu click on Build or Rebuild.

You can also set the builtByDefault property to true, then it is built when 
hitting ctrl-b.

>
> -Original Message-
> From: "Björn Schäpers" 
> To: qbs@qt-project.org
> Sent: Tue, 24 Nov 2020 9:21
> Subject: [Qbs] AutotestRunner in QtCreator
>
> Hi,
>
> I've added a AutotestRunner to my Project, but it does not show up in the
> Creator, I think this is because it does not create a binary, right?
>
> I've not looked into the code, but how feasible would it be to give the 
> Creator
> a fake executable to run the tests?
>
> Another idea I had, but not yet tested, is adding a dummy executable (just 
> empty
> main()) which depends on the Runner, then the tests should run, when I build 
> the
> dummy, right?
>
> Regards,
> Björn.
> ___
> 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] AutotestRunner in QtCreator

[Richard Weickelt]

What do you mean, it does not show up? It should show up as a product in the 
project view, but it is not built by default. In order to "run" it, you need to

1. have application products with the additional type autotest. Just write 
something like:

Application {
type: base.concat(["autotest"])
// ...

2. Build the AutorestRunner product explicitly. It will not show up under "run".

-Original Message-
From: "Björn Schäpers" 
To: qbs@qt-project.org
Sent: Tue, 24 Nov 2020 9:21
Subject: [Qbs] AutotestRunner in QtCreator

Hi,

I've added a AutotestRunner to my Project, but it does not show up in the 
Creator, I think this is because it does not create a binary, right?

I've not looked into the code, but how feasible would it be to give the Creator 
a fake executable to run the tests?

Another idea I had, but not yet tested, is adding a dummy executable (just 
empty 
main()) which depends on the Runner, then the tests should run, when I build 
the 
dummy, right?

Regards,
Björn.
___
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] 1.18 branch created

[Richard Weickelt]

Hello,

we branched off Qbs 1.18 recently. Scheduled release date for
version 1.18.0 is begin of December (together with Qt Creator 4.14) [1]. We
recommend users to try this branch with their projects and report back any
new problems they find. Snapshots of Qt Creator can then be obtained from [2].

Contributors are requested to push bug fixes and small, zero-risk
improvements to this branch, while features continue to go to master.

Patches currently under review can be moved if they are reasonably close to
finished.

Richard

[1] https://wiki.qt.io/Qt_Creator_Releases
[2] http://download.qt.io/snapshots/qtcreator/4.14/
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Cpp module for WebAssembly

[Richard Weickelt]

On 27.10.2020 12:27, Dan Pat wrote:
> You can provide your own cpp implementation by overriding the search
> path, but I don't see how you would be able to refer to the contents of
> the original directory. Note that the files there are implementation
> details and their presence and names cannot be relied upon. It's not a
> supported use case to derive from these items. So to achieve what you
> want, you'd have to copy the qbs module files you want to extend
> 
> 
> My fears confirmed.

If it is only for development on your machine and your ownly goal is to put
your module under version control in your product directory, then you can do:

import "/path/to/qbs/modules/cpp/GenericGcc.qbs" as GenericGcc

GenericGcc {
// hack hack hack
}

> 
> Out of curiosity: Which special features does it implement and why are
> they not suitable for upstreaming?
> 
>  
> The goal is to get qbs projects compiled to WebAssembly using the emscripten
> toolchain (and Qt WebAssembly). As for upstreaming: I have managed to come
> up with a working but hacky solution (a small test project) which I
> believe has room for improvement. 

This sounds fantastic! Keep on hacking and upload a patch soon. See
https://code.qt.io/cgit/qbs/qbs.git/tree/CONTRIBUTING.md

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

Re: [Qbs] How to explicitly prohibit the use of qt-framework in project

[Richard Weickelt]

>> qbs build ...  moduleProviders.Qt.qmakeFilePaths:/invalid
> Yes, it works. But is it possible to do such a disconnection from the
> project itself?

You mean in the project files? You can do that only on Product level, not
for the entire project:

Project {
   // cannot set global moduleProvider here.


CppApplication {
// 

moduleProviders.Qt.qmakeFilePaths: "/invalid"
}
}

> The fact is that I am developing a demo project, and I would like some
> products to be disabled when building, if the user does not have
> qt-framework installed.

I still don't get what you want to show. How Qbs behaves when Qt is not
found? You could also simply create two profiles:

1. with moduleProviders.Qt.qmakeFilePaths not set or set to a a valid path,
2. with moduleProviders.Qt.qmakeFilePaths set to invalid.

And then invoke Qbs with the two different profiles.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] How to explicitly prohibit the use of qt-framework in project

[Richard Weickelt]

Hi,

you may try 

qbs build ...  moduleProviders.Qt.qmakeFilePaths:/invalid

to configure a non-existing location. You can also set this property in your 
profile if you like.


-Original Message-
From: "Карелин Павел" 
To: qbs@qt-project.org
Sent: Mon, 19 Oct 2020 20:26
Subject: [Qbs] How to explicitly prohibit the use of qt-framework in project

Hi !

I need to check the build of the project for the case where qt-framework 
is not installed
For this I have created the following construction:

Depends { name: "Qt"; submodules: ["core", "network"]; required: false}
condition: Qt.core.present

Then in QtC I created a profile without qt-framework, and I tried to 
build the project. ... and the project was built.
It turned out that QBS found qt-framework on my system (Linux Kubuntu).

Question: to make the QBS strictly follow the the build profile, and 
does not look for qt-framework where they are not asked for it?

I use QBS 1.16

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

Re: [Qbs] Issues building for Android

[Richard Weickelt]

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

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

Our jobs can be found here:
https://code.qt.io/cgit/qbs/qbs.git/tree/.github/workflows/main.yml

Example test job (Qt for Android 5.14):
https://github.com/rweickelt/qbs/runs/1253245655

Docker image with Android SDK/NDK installed:
https://code.qt.io/cgit/qbs/qbs.git/tree/docker/focal/test-android.Dockerfile

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

The result of running

qbs setup-android --ndk-dir ${ANDROID_HOME}/ndk-bundle --sdk-dir
${ANDROID_HOME} --qt-dir ${QT_INSTALL_DIR} qbs_autotests-android-qt

is this:

profiles.qbs_autotests-android-qt.Android.ndk.ndkDir:
"/home/devel/android/ndk-bundle"
profiles.qbs_autotests-android-qt.Android.ndk.platform: "android-21"
profiles.qbs_autotests-android-qt.Android.sdk.ndkDir:
"/home/devel/android/ndk-bundle"
profiles.qbs_autotests-android-qt.Android.sdk.sdkDir: "/home/devel/android"
profiles.qbs_autotests-android-qt.moduleProviders.Qt.qmakeFilePaths:
"/opt/Qt/5.14.0/android/bin/qmake"
profiles.qbs_autotests-android-qt.qbs.architecture: ["armv7a", "x86_64"]
profiles.qbs_autotests-android-qt.qbs.targetPlatform: "android"
profiles.qbs_autotests-android-qt.qbs.toolchainType: "clang"

Taken from the linked job above.

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

Re: [Qbs] Issues building for Android

[Richard Weickelt]

Hi,

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

Raphael Cotty has done some effort to keep it working. We are running
regular tests for Qt 5.13 and 5.14 (multiple ABIs) in our CI. Qt 5.15 was
missing so far (https://bugreports.qt.io/projects/QBS/issues/QBS-1580), but
there is a good chance that this will be fixed soon.

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

Re: [Qbs] dependency tracking

[Richard Weickelt]

>> "testinput.h" file contains "#include "a.h" directive. Changing 
>> testinput.h results in a generator run followed by a C++ compiler run. 
>> Changing a.h results in no action, although in this case the generator 
>> is intended to reprocess its input.
> 
> It's expected that the generator won't re-run, because the dependency
> parsing happens when building a cpp file, i.e. all the headers are
> dependencies of the object file, and the header files themselves are only
> "passed through" by the scanning process. Though you might be able to
> cheat by setting up a dummy cpp file that includes the top-level header
> and making that an input to the generator rule.

As Christian said: The problem is that the cpp scanner is triggered by the
generated cpp file, but there is no connection to the testinput.h because
your cpp files is not including it.

If you could add the following lines to your generated cpp file:

#ifdef IGNORED
#include "testinput.h"
#endif

then this should be enough to make the cpp scanner think that you are
actually including testinput.h and hence, it will see and track a.h as well.

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

[Qbs] Qbs 1.17.0 released

[Richard Weickelt]

Hello,

I'd like to announce the release of Qbs 1.17.0 if you haven't seen the blog
post, yet. Source and binary packages as well as a change log can be found
at https://download.qt.io/official_releases/qbs/1.17.0/.
This release of Qbs is also shipped as part of Qt Creator 4.13.0.

Please refer to https://www.qt.io/blog/qbs-1-17-released for more details.

Thanks to everybody who contributed.

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

Re: [Qbs] How to use texttemplate module?

[Richard Weickelt]

> But then, wouldn't it be a good idea to add
> 
> additionalProductTypes: [product.texttemplate.outputTag]
> 
> to the texttemplate module? I see that several other modules are doing
> something like that. Would you consider a patch adding it?

I think the purpose of the text template module is to create intermediate 
artifacts that are consumed by other rules. This is also the reason for a 
configurable outputTag property. You can make the output a "final" artifact by 
customizing the product type manually as explained earlier. So I consider the 
current behavior to be the least surprising. But this is more my own opinion. 
If you can think of a good reason to adjust the additionalProductTypes 
property, then go ahead.

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

Re: [Qbs] Rule.Return dynamic list for outputArtifacts

[Richard Weickelt]

> However, yesterday I came across a small
> sip-file, and the generated cpp-files turned out to be not 6, but only 5.
> Naturally, my rule failed.
> 
> Question: how can I resolve my situation?
> Of course, I can tell the sip-generator to create fewer cpp-files (parameter
> -j), but I would like to understand - are there other ways?
> For example, to ignore section
> {
>    filePath: generatedFilesDir + "/sip" + moduleSipName + "part5.cpp",
>    fileTags: ["cpp"],
>    cpp: {
>  cxxFlags: sipCxxFlags
>    }
> }
> if the file ("sip" + moduleSipName + "part5.cpp") does not exist

The number of output files depends on the input file content and cannot be
known in advance? Then maybe this thread gives you some ideas:
https://www.mail-archive.com/qbs@qt-project.org/msg01022.html

The situation hasn't changed since then.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Deploying broken symbolic links?

[Richard Weickelt]

Hello Heiko,

> Is there any option to tell Qbs not to follow a symbolic link given
> within the "files" list?

This seems to be impossible, probably because Qbs for validity of source
artifacts. But you can write a rule that creates the symlink when building:

Product {
type: original.concat(["symlink"])

Rule {
requiresInputs: false

Artifact {
filePath: "link1.xxx"
fileTags: "symlink"
qbs.installDir: "dir1"
qbs.install: true
}

prepare: {
var cmd = new Command("ln", ["-sf", "destination",
output.filePath]);
cmd.highlight = "filegen";
cmd.description = "creating symbolic link '"
+ output.fileName + "'";
return cmd;
}
}
}

Unfornately a bit verbose though.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Applying cxxFlags to certain files

[Richard Weickelt]

On 10.07.2020 14:18, Иван Комиссаров wrote:
> You can access the original value via input.cpp.prop:
> 
> fileTags:[tag],
> 
> filePath:outputDir+"/"+FileInfo.baseName(input.fileName)+suffix,
> 
> cpp:{
> 
> includePaths:[].concat(input.cpp.includePaths,outputDir),
> 
> warningLevel:"none",
> 
> }
> 

Product should be available as well:

Artifact {
// ...
cpp.cxxFlags: product.cpp.cxxFlags.concat(["-flag"])
}

Another way would be, to add an additional unique filetag to your generated
artifacts and then use a Group to assign the additional cpp properties to
them. Something like that:

Module {
// ...
Rule {
// ...
Artifact {
// ...
fileTags: ["cpp", "specialtag"]
}
}
Group {
fileTagsFilter: "specialtag"
cpp.cxxFlags: outer.concat(["-flag"])
}
}

The Group item has the (fortunate or unfortunate) side effect that the
matching artifacts appear in Qt Creator as files of the product.




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

Re: [Qbs] Applying cxxFlags to certain files

[Richard Weickelt]

> Hi. I have a code generator, encapsulated in a dedicated Module, producing
> c++ source files. The generator's artifacts are then picked up by the
> "cpp"
> module according to the rules. For such generated files (and for them
> only)
> I would like to pass certain flags to the compiler (to suppress certain
> warnings) but I cannot figure out how. Any ideas are welcome. Regards.

Have a look at the code example here: 
https://doc.qt.io/qbs/qml-qbslanguageitems-artifact.html

If you use the outputArtifacts property of the Rule item instead, it should 
work very similar:

outputArtifacts: [{filePath: "myfile.cpp", fileTags: ["cpp"], cpp: { someFlag: 
"value" }}]


___
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] 1.17 branch created

[Richard Weickelt]

Hello,

we branched off Qbs 1.17 today. Scheduled release date for
version 1.17.0 is end of August (together with Qt Creator 4.13) [1]. We
recommend users to try this branch with their projects and report back any
new problems they find. Snapshots of Qt Creator can then be obtained from [2].

Contributors are requested to push bug fixes and small, zero-risk
improvements to this branch, while features continue to go to master.

Patches currently under review can be moved if they are reasonably close to
finished.

Richard

[1] https://wiki.qt.io/Qt_Creator_Releases
[2] http://download.qt.io/snapshots/qtcreator/4.13/
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] QBS script parsing speed

[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

[Richard Weickelt]

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

Some ideas:

1. Incremental project resolving: Take the dependency graph into account
when re-resolving a project so that unchanged products are not evaluated again.

2. Parallel resolving: Evaluate unrelated products using multiple threads.

Both would require a lot of refactoring work in the projectresolver and
moduleloader modules. I would really like to do something about it or see
somebody else doing something about it. But as a spare time job, this looks
undoable.

Nevertheless, we can try our best to make small steps forward.

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

Re: [Qbs] QBS script parsing speed

[Richard Weickelt]

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

I would like to understand why exactly this pattern makes the evaluation
time explode.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Evaluation of Conditional Depends

[Richard Weickelt]

> And of course the module's own properties set in the module file, except
> those referring to probes. But we do evaluate the module condition in a
> product context. Is that not the real product context or at least very
> close? E.g. if product sets moduleX.propA to true and depends on moduleX,
> is propA then not true when evaluating the condition? At least that was my
> expectation in my previous reply. Also, doesn't it make sense to provide
> access to custom product properties in that phase?

... And module properties set in the profile. I had a glance look at the source 
code. When evaluating the condition property, we are taking the following 
information from the product context into account:

- module values set in the profile (can even be a local profile within the 
product item)
- a fully(?) resolved instance of the qbs module

The result is then cached since this module might be loaded multiple times in 
the same product context. I don't see why we could not allow access to product 
as well as project properties and module properties set in the product item.

Christian, is that restriction by purpose?
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Evaluation of Conditional Depends

[Richard Weickelt]

Christian Kandeler wrote on 10. June 2020 10:09 (GMT +02:00):

> On Tue, 9 Jun 2020 20:55:43 +0200
> Christian Gudrian  wrote:
> 
>> Could it be that only a restricted set of variables is available during
>> evaluation of the module’s „condition“ property? Neither
>> „product“ nor any imported modules’ variables can be accessed
>> („Can’t find variable“ error).
>> 
>> Is that a known limitation or am I doing something wrong?
> 
> Remember that the module has not been loaded yet, so the right-hand side
> of the condition property is rather restricted in terms of what you can
> access there. Basically, it's just the qbs module.

And of course the module's own properties set in the module file, except those 
referring to probes. But we do evaluate the module condition in a product 
context. Is that not the real product context or at least very close? E.g. if 
product sets moduleX.propA to true and depends on moduleX, is propA then not 
true when evaluating the condition? At least that was my expectation in my 
previous reply. Also, doesn't it make sense to provide access to custom product 
properties in that phase?
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Evaluation of Conditional Depends

[Richard Weickelt]

Christian Gudrian wrote on 7. June 2020 10:48 (GMT +02:00):

> 

> I’ve put a simple example project on GitHub:
> https://github.com/cgudrian/QbsConfigurationDemo
> .
> 
> I am trying to implement basic Qbs support for the RT operating system
> ChibiOS (https://www.chibios.org ). It supports
> a wide range of hardware platforms and peripheral components and is highly
> configurable. The OS is statically linked into the finally binary.
> Specific Hardware support can be enabled and disabled at will.
> 
> The example code I have published tries to mimic the original source code
> layout and „supports“ two types of peripheral components: ADC and CAN.
> Each peripheral component consists of a generic, abstract part in the OS
> and a corresponding (low level) driver implementation which might come in
> different versions depending on the specific board the build is targeting.
> 
> What I would like to end up with is the following:
> 
> RTOSApplication {
>   RTOS.enableADC: true
>   Depends { name: "boards.Board1“ }
>   file: "main.c"
> }
> 
> Qbs has to
>   - include the needed source files both for the OS and the driver
>   - set the appropriate compiler defines
>   - set the appropriate include paths
> 
> Currently the board modules depend on the concrete drivers modules
> conditionally. By using this design the list properties (sourceFiles,
> defines, includePaths) automatically get appended to instead of replaced.
> And it is exactly these conditional dependencies that do not work.
> 
> The modules A, B and C from my original post map to the modules in my
> example as follows:
> 
> ModuleA -> RTOS
> ModuleB -> board.Board1, board.Board2
> ModuleC -> driver.adc.v1, driver.adc.v2, driver.can.v1

You are setting values of the RTOS Module in the product. But I think module 
values from there do not populate when loading other modules unless you set 
them in the module itself (set Rtos.enableAdc in the board module). You may 
either:

1. Make enableAdc & friends a property of RtosApplication and use 
product.enableAdc in the conditional Depends item because product properties do 
populate.

2. Make enableAdc a property of the board module and set this one in your 
application.

Something you might not be aware of: Qbs can handle multiple module variants in 
the same folder. You need to add a expression in the modules' condition that 
evaluates to true only for one module variant. That is how the cpp module does 
it with toolchainType. The variants could even be located in different 
locations in the fs as long as the folder structure is the same and all module 
subtrees are in qbsSearchPaths. 

That way you could have a single board module with x variants and a single ADC 
driver module with different versions in separate files. You would then set for 
instance board.type in your application and the board module would set 
add.version. You may use inheritance for sharing property definitions. This is 
not so obvious, thus study the cpp module. I think this would simplify your 
module structure a lot. 

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

Re: [Qbs] Evaluation of Conditional Depends

[Richard Weickelt]

> In ModuleA there is a property enableFeature which by default is false.
> 
> ModuleB conditionally depends on ModuleC, if ModuleA.enableFeature is true.
> 
> A Product depends on ModuleA and ModuleB and sets ModuleA.enableFeature to 
> true. However, ModuleC is not used as a dependency.

Could you clarify the relationship between ModuleA and ModuleB? Maybe post
some minimal example code.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Using ConanfileProbe with yocto cross compiling toolchain

[Richard Weickelt]

> I archived my goal with the following code:

Good to hear. Thanks for posting the code.

> But this code has some restrictions (like using bash or zsh but not fish).

I wouldn't consider it a restriction not to support an exotic shell.

> Thus I don't think that it should be made into the official Qbs codebase.
> Maybe this code could be used in some How-To section or something.

What's your experience in using Qbs with Yocto? Once you solved the
EnvironmentScriptProbe, were there a lot of additional steps needed? Any
pitfalls? I guess a howto would be nice in general and might be interesting
for some people. On the other hand - and without having much knowledge about
yocto - how high is the risk that this howto would be outdated by tomorrow?

> If you really want me to contribute this as a "YoctoEnvironmentProbe",
> despite the restrictions, I will do some cleanup an contribute it.

Probing exported environment variables from a shell script deserves a
generic probe. If you could make it work for .bat and ps1 as well, even
better. Don't forget to add a testcase in test_blackbox.cpp.

Thank you for you contribution.

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

Re: [Qbs] setup-android, no --system?

[Richard Weickelt]

> Thanks for the detailed explanation, i've been looking at your scripts
> and docker files recently (and have adopted your install-qt.sh! ;))
> I think we don't have the same use case, you need to build and test
> qbs, i need to build and test a android+qt+qbs container that works
> "out of the box" whichever way it is used (CI or developers).

Yes, that is almost what this container is about:
https://code.qt.io/cgit/qbs/qbs.git/tree/docker/bionic/test-android.Dockerfile,
except that we do not install Qbs in it which is one line to add.

We don't build Qbs in this image, but only run the Android autotests. Qbs is
built in another container and we only mount the build results into this
container. We don't do the qbs-setup-android stuff during image creation for
that particular reason.

> Basically my ultimate test is: build and sign an hello world APK with
> this android+qt+qbs container, that depends on all the Qt modules i
> want to be available to developers.
> My goal is: just run "qbs build" in the right container and you'll get
> a signed APK.

Yes, that sounds neat and should just work with above image, except that it
misses the setup-android step, but that is only a few lines to add. Have a
look at:
https://code.qt.io/cgit/qbs/qbs.git/tree/docker/bionic/Dockerfile#n190

That's all.

> I was just surprised that --system is supported by all qbs
> setup/config tools but qbs-setup-android. I don't see any compelling
> reason for that, do you?
> Maybe it was simply never needed, hence never implemented.

Probably. It's a valid suggestion though. Wanna submit a patch?

> As a side note, i don't install Android the same way. I use what i
> believe is the new approach: install commandline-tools first, and run
> sdk manager with a package requirement file, here is mine right now:
> build-tools;28.0.3
> ndk;21.0.6113669
> patcher;v4
> platform-tools
> platforms;android-28

Ah thanks. That looks helpful. We should do the same. It would be nice if
you could post a more comprehensive code snippet once you are done.

> Digression: I wish Qbs was in the list of tools i can install with
> install-qt.sh ...

We don't supply stand-alone binary packages yet, but you can install
qtcreator which is only a few hundred MB overhead ;-)

./scripts/install-qt.sh -d ${QT_INSTALL_DIR} --version
${QTCREATOR_VERSION} qtcreator

Feel free to strip some folders from the installation.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] setup-android, no --system?

[Richard Weickelt]

> Because this file will end up in some "home" directory, which might
> not be accessible to the end user (eg. custom UID, GID, home, ...)
> Having a system wide qbs conf is bullet-proof in that regard.
> So, yes i would prefer to run the above command, but with '--system'
> and no, you cannot simply move the generated user's conf into
> /etc/xdg/qbs, they don't use the same 'ini' namespace

Until we are able to run the Docker daemon as non-root user, I am using this
approach:

1. set up a user XXX and use whatever uid/gid you like (e.g. 1000).

https://code.qt.io/cgit/qbs/qbs.git/tree/docker/bionic/test-android.Dockerfile

2. enable password-less sudo for this user
3. switch to that user before running qbs config to set up the profiles
4. Running the container, mount the current folder as the working dir
3. add an entrypoint script that looks at the uid/gid of the
   working dir and adjust the uid/gid of XXX in the container
   to match it.
   https://code.qt.io/cgit/qbs/qbs.git/tree/docker/bionic/entrypoint.sh

5. Run the container with docker-compose which cuts the Docker command line
down to:
  docker-compose run --rm IMAGESERVICENAME qbs build ...

   https://code.qt.io/cgit/qbs/qbs.git/tree/docker-compose.yml
   Docker-compose mounts the current directory and does additional stuff
   for you. I always have a docker-compose.yml in projects where
   the build environment is in a Docker container.

You can see it in action here:
https://code.qt.io/cgit/qbs/qbs.git/tree/.travis.yml#n75
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] setup-android, no --system?

[Richard Weickelt]

> I find this quite useful when creating docker container.
> The idea is that the container (name) completely define the whole
> build config, and running "qbs build" in there build an APK with the
> "right" configuration.
> No env involved, no foreknowledge of the profile name, it just work
> out of the box.
> 
> My current solution is to add an hand crafted /etc/xdg/qbs/qbs.conf,
> but i would prefer to generate it with qbs-setup-android and
> qbs-config from the Dockerfile.

A hand-crafted qbs.conf sounds like overkill. Why can't you just run
something like

qbs setup-android --ndk-dir ${ANDROID_HOME}/ndk-bundle --sdk-dir
${ANDROID_HOME} --qt-dir ${QT_INSTALL_DIR} qbs_autotests-android-qt

qbs config defaultProfile qbs_autotests-android-qt

in the Dockerfile? You need to install all the Android stuff and Qt anyway,
so you must have that information already.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Using ConanfileProbe with yocto cross compiling toolchain

[Richard Weickelt]

> Sorry. I meant how to extract the environment variables from the yocto script.
> My idea was to source the script in a process
> with https://doc.qt.io/qbs/jsextension-process.html 
> and then just query all the process environment variables with
> https://doc.qt.io/qbs/jsextension-environment.html#currentenv.
> This way I would not need to parse the yocto script myself in the
> "YoctoEnvProbe".

Maybe you can write another script that
1. prints the environment variables
2. then sources the yocto script
3. then prints the environment variables again

Run this script in a Probe (with an appropriate shell) and parse the output
somehow. You may also omit step 1 and just use all environment variables
printed by script.

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

Re: [Qbs] Using ConanfileProbe with yocto cross compiling toolchain

[Richard Weickelt]

> I will try this approach. But maybe I use `conan install -e` instead of
> setting the environment variables for the complete process.

If the result is the same, then why not.

> Do you know how I can easily extract the environment variables?
>  https://doc.qt.io/qbs/jsextension-environment.html#currentenv  seems like a
> solution but I don't know how to access a process environment with this.

Which environment variables? If I understood you correctly, then you have
environment variables generated by yocto in a file/script which you need to
parse somehow in a probe. There is no probe for that, you would have to
implement your own.

If the environment variables are already in the environment when calling qbs
resolve (for instance by sourcing the script in the shell), then
ConanfileProbe should already have them.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Using ConanfileProbe with yocto cross compiling toolchain

[Richard Weickelt]

> I just stumbled across a scenario in which we use with multiple profiles for
> different cross compiling toolchains. Yocto creates a script which exports
> environment variables. We normally just extract the needed values from the
> script and set them as additional qbs profile settings.
> This leads to the problem that the ConanfileProbe just calls "conan
> install... -p..." without the needed environment variables. 
> Thus when
> install libraries they are getting compiled with the wrong toolchain/settings.
> What is the proper way of doing this? How do I set the
> environment variables? Should I set the variables in the Kit?

That would be one option, but sounds a bit inconvenient. If the environment
variables are only relevant when running the ConanfileProbe, then you would
need to:

1. Add an additionalEnvironmentVariables property to ConanfileProbe
2. Append these to the process environment in ConanfileProbe. See
   https://doc.qt.io/qbs/jsextension-process.html#setenv
3. Add an additional Probe item in your project file that extracts
   the environment variables from the script.
   Probes are currently executed in the order of their appearance in the qbs
   file, so make sure it comes first.

Would that be a solution for you? Then I would warmthly welcome a patch.

Note that instead of modifying qbs profile settings globally with your yocto
variables, you should be able to also create an intermediate Profile item in
your project files this way:

Project {
YoctoScriptProbe {
id: yocto
}
// This profile amends the profile set by Qt Creator or on the
// command line
Profile {
name: "yocto-profile"
baseProfile: project.profile
someModule.someProperty: yocto.someExtractedValue
}

// Every product now needs to specify the amended profile
// explicitly
Product {
profile: "yocto-profile"
}
}

Hope that helps.

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

Re: [Qbs] Android multiarch

[Richard Weickelt]

> As an experiment, i've just tried Qt-5.14, and this has enabled
> multi-arch on Android.
> I can select the list of architecture i want to support with 
> qbs.architectures.
> This works for libraries, but my application is disabled:
> Error while handling 'TestApp'
> Product 'TestApp' had errors and was disabled.
> 
> 3 of them, and that's all i get. I have 3 Depends that point to
> internal libraries, maybe that's the smoking gun...
> I have
> multiplexByQbsProperties: ["architectures"]
> qbs.architectures: ["arm64", "x86_64"]
> For libs and apps.
> I tried as well the 'usesNativeCode' but no success.
> 
> Any idea what i'm missing?

Can you show us some more code or even a minimal example?
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Qtc: Cannot find the androiddeploy Json file

[Richard Weickelt]

> When i want to "run" on the device:
> Initializing deployment to Android device/simulator
> Deploying to 150c980e8288de07
> Cannot find the androiddeploy Json file.
> Error while building/deploying project Neon Factory Tools (kit:
> Android for arm64-v8a (Clang Qt 5.12.8 for Android ARM64-v8a))
> When executing step "Deploy to Android device"
> 
> I think this happens only when i do cosmetic changes in my qbs files.
> The only way to recover is to trigger a manual build, changing a
> source file is not enough.
> 
> Any idea what's goind on?
> Looks to me this problem is on QtC side.

A quick guess and without ever having built an Android project: The selected
product is the application executable and thus, none of the subsequent rules
is executed. Could that explain it? Have a look at
https://code.qt.io/cgit/qbs/qbs.git/tree/share/qbs/module-providers/Qt/templates/android_support.qbs
There is a rule that produces qt_androiddeployqt_input (the json file) which
I guess is not requested when you press the "run" button. There are also
subsequent rules responsible for the deployment.

You could add one of the rule's output to your product type, although I
guess there is a cleaner way of doing it.

YourAndroidProduct {
type: base.concat("bundled_jar")
}
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

[Qbs] Qbs 1.15.0 released

[Richard Weickelt]

Hello,

I'd like to announce the release of Qbs 1.16.0 if you haven't seen the blog
post, yet. Source and binary packages as well as a change log can be found
at https://download.qt.io/official_releases/qbs/1.16.0/.
This release of Qbs is also shipped as part of Qt Creator 4.12.0.

Please refer to https://www.qt.io/blog/qbs-1.16.0-released for more details.

Thanks to everybody who contributed.

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

Re: [Qbs] Mingw issues

[Richard Weickelt]

> It looks like the value of
> `profiles.mxe-i686-w64-mingw32-static.cpp.toolchainPrefix` was
> incomplete (you can see it from the config pasted above). It should have
> been "i686-w64-mingw32.static-", and after changing it to that value,
> the build started.
> 
> So, actually, my problem is solved. It would be super cool if QBS was so
> smart to automatically detect the correct baseProfile to be used when I
> point it to a qmake provided by MXE, and I still need to figure out why
> the toolchainPrefix was only set to `i686-w64`.
I think qbs-setup-toolchains got confused by the "." in the toolchain
prefix. It is usually not expected. The heuristics have been improved in Qbs
1.16. Could you try if it works with the release candidate of Qt Creator
4.12 and otherwise submit a patch for
https://code.qt.io/cgit/qbs/qbs.git/tree/src/app/qbs-setup-toolchains/gccprobe.cpp
?
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Mingw issues

[Richard Weickelt]

Alberto Mardegan wrote on 5. Apr 2020 18:52 (GMT +02:00):

> Hi all!
>  I've a feeling I've met this problem before, but I cannot remember
> what the solution was. So here I am again :-)
> 
> I'm trying to build an application for Linux, using QBS with MXE. I've
> setup my toolchain like this:
> 
> MXE_DIR=/mnt/Lavoro/mxe/mxe-qt5.9
> qbs setup-toolchains $MXE_DIR/usr/bin/i686-w64-mingw32.static-g++
> mxe-i686-w64-mingw32.static
> 
> # The above didn't recognize my compiler, so these two were needed:
> qbs config
> profiles.mxe-i686-w64-mingw32-static.cpp.cxxCompilerName:i686-w64-mingw32.static-g++
> qbs config
> profiles.mxe-i686-w64-mingw32-static.cpp.cCompilerName:i686-w64-mingw32.static-gcc
> 
> # Then, add Qt:
> qbs setup-qt $MXE_DIR/usr/i686-w64-mingw32.static/qt5/bin/qmake
> mxe-qt59-i686-w64-mingw32-static
> 
> # use the MXE toolchain:
> qbs config
> profiles.mxe-qt59-i686-w64-mingw32-static.baseProfile:profiles.mxe-i686-w64-mingw32-static
> 
> But then, when I run qbs on my program, it spits out a few errors:
> 
> 
> Build graph does not yet exist for configuration 'default'. Starting
> from scratch.
> Resolving project for configuration default
> Setting up Qt at
> '/mnt/Lavoro/mxe/mxe-qt5.9/usr/i686-w64-mingw32.static/qt5/bin/qmake'...
> Qt was set up successfully.
> ERROR: /home/mardy/src/git/mappero/lib/Mappero/Mappero.qbs:3:1 Error
> while handling product 'Mappero':
> /home/mardy/src/git/mappero/lib/Mappero/Mappero.qbs:61:5 Module Qt.core
> could not be loaded.
> /home/mardy/src/git/mappero/lib/Mappero/Mappero.qbs:62:5 Module Qt.gui
> could not be loaded.
> /home/mardy/src/git/mappero/lib/Mappero/Mappero.qbs:63:5 Module Qt.qml
> could not be loaded.
> /home/mardy/src/git/mappero/lib/MapperoUi/MapperoUi.qbs:3:1 Error while
> handling product 'MapperoUi':
> /home/mardy/src/git/mappero/lib/MapperoUi/MapperoUi.qbs:49:5 Module
> Qt.core could not be loaded.
> /home/mardy/src/git/mappero/lib/MapperoUi/MapperoUi.qbs:50:5 Module
> Qt.quick could not be loaded.
> /home/mardy/src/git/mappero/src/qt/qt.qbs:4:1 Error while handling
> product 'mappero':
> /usr/local/share/qbs/imports/qbs/base/QtGuiApplication.qbs:32:5 Module
> Qt.gui could not be loaded.
> /home/mardy/src/git/mappero/src/qt/qt.qbs:125:5 Module Qt.core could not
> be loaded.
> /home/mardy/src/git/mappero/src/qt/qt.qbs:126:5 Module Qt.quick could
> not be loaded.
> /home/mardy/src/git/mappero/src/qt/qt.qbs:128:5 Module Qt.widgets could
> not be loaded.
> /home/mardy/src/git/mappero/src/qt/qt.qbs:135:5 Module Qt.concurrent
> could not be loaded.
> 
> 
> These modules seem, however, to have been proeprly setup. I do have, for
> example:
> 
>  default/genmodules/Qt/c0b33115f511456a/modules/Qt/core/core.qbs
> 
> 
> Any hints on how to further debug the issue?
> 
> 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
> 

Does your toolchain setup work without Qt? Maybe build a plain c++ hello world 
app.

Is the deduced qbs.architecture correct?
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Building Qbs for conan/bintray on Gitlab

[Richard Weickelt]

> Oh. Interesting. I did not saw that the plugins are not compiled. But I
> don't know why. If you look into conanfile.py it just calls
> 
> qmake -r qbs/qbs.pro  CONFIG+=qbs_no_dev_install 
> CONFIG+=qbs_no_man_install CONFIG+=qbs_use_bundled_qtscript
> 
> Followed by a simple
> 
> make -j1 // tools.cpu_count() will return 1 since every container just 
> get 1 core assigned by gitlab.com  gitlab-ci
> 
> So something has to be wrong with the generated Makefiles? Should I try
> to archive the generated Makefiles for further analysis?

I am not looking forward to reading makefiles. It is a bit strange that this
cannot be reproduced locally, even with Docker. Does it work when building
against a dynamically linked Qt installation? Note that we can bundle Qt
together with Qbs, but only when building Qbs with Qbs.

I am looking into publishing prebuilt executables for all platforms for Qbs
1.16.0, at least as tarballs/zips. So one fall-back option might be to just
download this and package it up for Conan, just like what they do with CMake
and other tools.

> Yes, I would contribute maintain a Qbs Conan package. But if it should be
> an "official" Qbs Conan Package I would like to get some constraints
> like: where to host the packaging code; how to name the bintray etc.

Looks like bincrafters conventions are:

- open a ticket with a package request (refer to
https://github.com/bincrafters/community)
- recipe in a repo "conan-PACKAGE" (https://github.com/bincrafters)
- specific repository layout with conanfile.py and data yml files for
  each version

Package name "Qbs" or "qbs" should be fine.

Would be great to have it there. This should make it very easy to get the
package to conan-center.

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

Re: [Qbs] Building Qbs for conan/bintray on Gitlab

[Richard Weickelt]

Hello,

> I try to build a Qbs conan package (with static linked Qt) so conan could
> just install Qbs with a simple "build_requires". Building the conan package
> works fine on my local machine. But when I use Gitlab-CI to build the
> packages it fails to build.
> To build locally I use the following Dockerfile:
> 
> FROM conanio/gcc8
> 
> ENV CONAN_USERNAME="psy-kai" \
>     CONAN_CHANNEL="testing" \
>     CONAN_GCC_VERSIONS="8" \
>    
> CONAN_REMOTES="https://api.bintray.com/conan/bincrafters/public-conan@True@bincrafters";
> 
> RUN sudo pip install --upgrade conan_package_tools && \
>     conan user
> 
> COPY *.py .
> COPY test_package test_package
> RUN python build.py
> 
> Placing this into the cloned repo and running "docker build" works just fine.
> The complete build output of the crashing gitlab-ci build can be found
> at https://gitlab.com/Psy-Kai/conan-qbs/-/jobs/480352993.

I don't see compiler/linker invocations for any of the plugins in the gitlab
output, so it seems to be a build system issue. When running locally in a
Docker container, Qbs builds correctly. I have put above lines (without
invoking python build.py) in a Dockerfile and ran

docker build

Then I started a container with

docker run -it --rm -v $PWD:/builds -w /builds qbsconan

and invoked the build with

docker exec CONTAINER_ID python build.py

I guess this is a bit closer to what gitlab is doing, but maybe not 100%. So
what could be the difference?

> I think a pre-build Qbs
> conan package would help a lot, especially when using CI systems.

Yes, a Qbs Conan package in the bincrafters repo or in
https://conan.io/center/ would be great. I thought about just packaging
prebuilt binaries containing bundled Qt libraries as a first step for the
1.16 release. The next Qbs release could then be built from source using the
Qbs Conan package.

But if you manage to build Qbs from source in a Conan recipe using
bincrafters' Qt package, even better. Would you contribute and maintain a
Qbs Conan package?

> Additionally some off topic: the documentation for the ConanfileProbe
> does not match with the current implementation. Maybe you should fix the
> docs before 1.16 release ;)

In an open source project where almost all participants invest their spare
time to create something useful, it is good practice to not let others
guess. Would you mind sharing your findings? You may file a bug report or
submit a fix right away.

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

Re: [Qbs] Building code generator and its dependencies for a different architecture than the rest of the products

[Richard Weickelt]

> I think I almost got it to work. The problem I have now is that the app
> seems to link against the wrong version of the library:
> 
> ld: warning: ignoring file
> /.../lib.eyJwcm9maWxlIjoiaG9zdFByb2ZpbGUifQ--.cd69e9f1/.tmp/lib, building
> for iOS-arm64 but attempting to link with file built for macOS-x86_64
> Project {
>     Profile {
>         name: "hostProfile"
>         qbs.targetPlatform: "macos"
>     }
> 
>     Profile {
>         name: "targetProfile"
>         baseProfile: project.profile
>     }
> 
>     DynamicLibrary {
>         name: "lib"
>         files: ["lib.cpp"]
>         multiplexByQbsProperties: ["profiles"]
> 
>         qbs.profiles: ["hostProfile", "targetProfile"]
> 
>         Depends { name: "cpp" }
>     }
> 
>     CppApplication {
>         consoleApplication: true
>         name: "gen"
>         files: ["gen.cpp"]
> 
>         qbs.profile: "hostProfile"
> 
>         Depends { name: "lib" }
>     }
> 
>     CppApplication {
>         name: "app"
>         files: ["gen.cpp"]
> 
>         Depends { name: "lib" }
>     }
> }

Looking at your project: Lib is multiplexed while app is not. Lib does not
have an aggregator. App does not constraint the dependency on lib.

In that case Qbs resoles the dependency as follows: app depends on all
variants of lib at the same time ("hostProfile" and "targetProfile"). I
think this could explain the error you are seeing and should be case 3b in
both, Qbs 1.15 and 1.16:
https://code.qt.io/cgit/qbs/qbs.git/tree/src/lib/corelib/language/moduleloader.cpp?h=1.15#n1108
https://code.qt.io/cgit/qbs/qbs.git/tree/src/lib/corelib/language/moduleloader.cpp?h=1.16#n1148

(Dependency matching will be a bit relaxed in Qbs 1.16, but it shouldn't
affect your case at all).

I think you should write:

CppApplication {
name: "app"
files: ["gen.cpp"]

Depends { name: "lib"; profiles: "targetProfile" }
}

to constraint the dependency (and make case 3c.).

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

[Qbs] 1.16 branch created

[Richard Weickelt]

Hello,

we branched off qbs 1.16 today. Scheduled release date for
version 1.16.0 is mid of April (together with Qt Creator 4.12) [1]. We
recommend users to try this branch with their projects and report back any
new problems they find. Snapshots of Qt Creator can then be obtained from [2].

Contributors are requested to push bug fixes and small, zero-risk
improvements to this branch, while features continue to go to master.

Patches currently on gerrit can be moved if they are reasonably close to
finished.

Richard

[1] https://wiki.qt.io/Qt_Creator_Releases
[2] http://download.qt.io/snapshots/qtcreator/4.12/

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

Re: [Qbs] Exporting libraries to link only for MinGW

[Richard Weickelt]

> You don't need a group here in the first place. Just
> cpp.dynamicLibraries: {
>var libs = [];
>if(qbs.toolchain.contains("mingw"))
>libs = libs.concat(["pthread", "ole32"] )
>return libs;
> }

Or to be more explicit: You **must** not use the Group item for this purpose. 
The Group item selects file artifacts by name or tag and assigns module 
properties to them. Since You don’t select any artifacts, the Group has no 
effect. You probably want to use the Properties item (which works in modules as 
well. The limitation is that only one Properties item should write the same 
module property at a time (mutual exclusive). But that seems to be the case in 
your example.

Richard___
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

[Richard Weickelt]

Jochen,

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

This should not be the case. Probes are cached by the location of their
definition and the input properties (snapshot before running configure).

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

It would be great if Qbs 1.16 could offer a complete Conan story. We have
roughly a month until feature freeze.

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

It might be beneficial if module providers:

a. could define their own probe items.
b. have access to the project and the product they live in.
c. could be set up in projects like it is possible in products

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.

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

You can define custom properties for your module provider.

Are you aware that module providers operate on product level? You can
(currently) configure them in the profile and in the product. Would the
following approach do what you want?

// module-providers/conan/provider.qbs
// Sets up a module for each key in dependencies
ModuleProvider {
property var dependencies
// ...
}

Project {

property var dependencies: conan.dependencies

// https://codereview.qt-project.org/c/qbs/qbs/+/288927
Probes.ConanfileProbe {
id: conan
conanfilePath: "conanfile.py"
}

Product {
Depends { name: "conan.somelib" }
moduleProviders.conan.dependencies: project.dependencies
}
}

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

True. There should be a way to select fallback providers. At least you can
override the fallback provider by putting your own provider into a
somePath/module-providers/__fallback folder and add somePath to qbsSearchPaths.

I wonder how a better and generic solution would look like. We could add a
moduleProviders.defaultFallbackProvider configuration option or we could
replace Depends.enableFallback by Depends.providers and then explicitly
specify a pro

Re: [Qbs] Construction project.buildDirectory

[Richard Weickelt]

> sorry for breaking this. The issue has been fixed by
> https://codereview.qt-project.org/c/qbs/qbs/+/289271 and the fix will be in
> Qt Creator 4.11.1 which is about to be released this week. You may try
> http://download.qt.io/snapshots/qtcreator/4.11/4.11.1/187/ or just wait for
> the official release.

I have to take that back. Qt creator 4.11.1 still ships Qbs 1.15.0. The tag
was unfortunately made from an older commit. However,
http://download.qt.io/snapshots/qtcreator/4.11/4.11.1/187/ contains an
updated Qbs (1.15.1) containing the fix. We are aiming for Qbs 1.16.0
together with Qt Creator 4.12.0.

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

Re: [Qbs] Construction project.buildDirectory

[Richard Weickelt]

Hello Pavel,

>> Some code has been moved around to fix a different problem with
>> Project-level probes, so this appears to be a side effect of that. 
>> However, you can just leave off the "project.", and it will work both
>> with 1.15 and 1.14.
> Yes, i did so. But I wanted to find out if the previous behavior would
> be restored. This is about syntactic sugar: I would like for the whole
> project to have a uniform construction of "project.buildDirectory"

sorry for breaking this. The issue has been fixed by
https://codereview.qt-project.org/c/qbs/qbs/+/289271 and the fix will be in
Qt Creator 4.11.1 which is about to be released this week. You may try
http://download.qt.io/snapshots/qtcreator/4.11/4.11.1/187/ or just wait for
the official release.

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

Re: [Qbs] Interfacing Qbs to Conan

[Richard Weickelt]

Hello Leon,

I am really glad to read that Clausmark is looking into interfacing Qbs with
Conan. Since Conan gets more and more traction and brings great advantages,
Qbs should support it well. That's why I want to share some more detailed
thoughts on this topic. I'll start with what I originally had in mind and
later get to module providers.

> Here's the probe. I is instantiated at project level where the value of
> 'generatedQbsFilePath' is added to the 'references' property. If you run
> it like this, 'targetArch' will be undefined.

I assume that this has already been sufficiently answered and since I was
told that you are now trying to implemented a conan module provider, I will
not comment on it. However, I had this topic on my personal backlog for a
while and came up with the following probe (WIP):
https://codereview.qt-project.org/c/qbs/qbs/+/288927

You may find this useful and I would be glad to get feedback.

> How would I access a property set in a profile? I think I've tried it
> before but I probably did something wrong.

Module properties set in profiles are only accessible from within products
and modules.

> Also in the blog post about the release of qbs 1.15.0 it says the
> following: Probes on the project level are now evaluated before Profile
> items. That way a Qbs project can easily interface to package managers
> like Conan or vcpkg and resolve all build dependencies including compiler
> toolchains in a clean and platform-agnostic way. [...]

As Christian already wrote, this is about Profile items. My assumption is
the following:

1. When using Conan, you want to package up _everything_ necessary to build
your project. Not only the relevant libaries, but also toolchains. You want
to have the same tools on every computer as well as in your CI system and
you might have different host operating systems.

2. You have modules for all relevant libraries and your only problem is the
connection from your conanfile to setting up these modules.

3. You do not want to or cannot use conan's qbs generator because your
packages are missing important meta information or do not fit into conan's
standard layout. Conan't built-in qbs generator is very inflexible.

Thus, I thought users could write a simple Probe to run conan install and
extract all relevant meta information from the resulting
conanbuildinfo.json. Since Probe items are now executed before Profile items
are evaluated, users could do something like:

Project {
Probes.ConanfileProbe {
id: conan
conanfilePath: path + "/conanfile.py"
options: ({someOpt: "bla"})
}

Profile {
name: "gcc"
mylib.includePaths: conan.dependencies["mylib"].include_paths
qbs.toolchain: "gcc"
cpp.installPath: conan.dependencies["gcc-arm-none-eabi"].rootpath +
 "/bin"
}
}

This way you could set up a completely self-containing project and you would
never again mess around with manual dependency installation on your computer
(toolchains included). Note how simple, straight-forward and
easy-to-understand this is compared to how CMake interacts with Conan.

However, there is unfortunately a limitation: Qt Creator is not able to use
profiles with a custom name specified in a project. Qt Creator can only
invoke builds with its own cryptic profile naming scheme (for instance
qtc_Desktop__9d3c5e00). One possible, but ugly work-around for this problem
is to create a dummy profile that shadows an existing profile in Qt Creator.
Like this:

Profile {
name: "qtc_Desktop__9d3c5e00"
baseProfile: "gcc"
}

Qbs will then no longer use the values from Qt Creator's own profiles, but
the ones set in the Profile item in the project. That means, developer
participating in the project would need to add such a dummy Profile item to
the project which is not really what we want.

I think it would be a great improvement in QtCreator to extract Qbs' Profile
items as read-only kits when opening a Qbs project. And it would be multiple
times easier than anything existing today.

> Doesn't that mean that profile specific properties are inaccessible at
> the time the probe is evaluated?

True (on project-level). The "qbs" module is a bit special because it is
loaded very early and is always implicitly available everywhere. The
qbs.architecture property is another oddity because if it is not set by the
profile, it will be set later by the cpp module.

> How would I reference the qbs file generated by conan though? I'm only
> doing it with this project level probe because I thought there was no
> other way, or is there?

If you want to reference the qbs file created by conan's qbs generator, then
yes, would need a probe on Project level invoking conan install
/path/to/conanfile -g qbs ... The qbs file should be generated somewhere
under project.buildDirectory.

Back to the topic of module providers, I do think that your idea to write a
generic module provider for Conan is a great i

Re: [Qbs] Passing paths to properties

[Richard Weickelt]

> I believe that most other properies which accept a path (like installDir,
> and the prefix property within a Group) all happily accept a relative
> path, so can we consider this a bug in Android.sdk?

You mean qbs.installDir? That is - by definition - relative to qbs.installRoot.

> Also, while thinking about a solution to this, I was thinking that a 
> resolvePath() method in the FileInfo service could be useful:
> 
> var path = ... // absolute or relative var absolutePath =
> FileInfo.resolvePath(path, basePath);
> 
> which would return path, if it's already absolute, or join it with 
> basePath if path is relative.
> 
> Would this be a useful addition, or do we already have something like 
> this in QBS?

This and in addition - since the documentation already calls the property a
"path" [1] - introduce a path property type in Qbs which does that
automatically for us in its toString() method.

[1] https://doc.qt.io/qbs/qml-qbsmodules-android-sdk.html#sourcesDir-prop
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Accessing qbs.architecture in Probe

[Richard Weickelt]

>> Here's the probe. I is instantiated at project level where the value of
>> 'generatedQbsFilePath' is added to the 'references' property.

Leon, would you please post your probe code to the mailing list? I am
generally interested in Qbs Conan integration and would like to see how
others do it.

> That's generally a problem. Modules are per-product, and with very few
> exceptions (constants like qbs.hostOS) will not have proper values on the
> project level. Though it will still work if you set the architecture via
> a profile.

If you know what architecture your project will be built for, specify a
project property and set this from command line (or in Qt Creator).

Note that such an architecture-agnostic Conan probe breaks if you are going
to multiplex a product over different architectures. In that case it would
better to put the probe into the product or even a separate module. Make
every product in your project depend on that module. The probe should only
run a single time for the whole project. Then you should be able to use
properties from the qbs module as inputs of the probe.

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

Re: [Qbs] QBS behaviour while linking

[Richard Weickelt]

Hi,

> Hmm ... I observe that the "Compile Output" inside QtC sometimes stops while 
> linking a library and (using htop) one can see that no other core is used. 
> After that further compilations can be seen.
> Maybe the linking of the component A has to be completely finished before 
> compiling other files (which might be part of component B which depends on A)?

should not be the case in a plain C/C++ project. Dependencies are tracked on 
artifact level which means compilation of product B depending on A can happen 
while A is being linked. Just the linkage of B is postponed until A has 
completed. Do you have a (minimal) reproduce example showing that behavior?

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

[Qbs] Qbs 1.15.0 released

[Richard Weickelt]

Hello,

I'd like to announce the release of Qbs 1.15.0. Source and binary
packages as well as a change log can be found at
https://download.qt.io/official_releases/qbs/1.15.0/.
This release of Qbs is also shipped as part of Qt Creator 4.11.0.

Please refer to https://www.qt.io/blog/qbs-1.15.0-released for more details.

Thanks to everybody who contributed.

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

Re: [Qbs] Deployment and dependency bundling

[Richard Weickelt]

> I've got it working to some point by adding these properties to the Rule:
> 
> inputsFromDependencies: ["application", "dynamiclibrary"]
> multiplex: true
> outputFileTags: ["deployed_library"]
> 
> but this causes the Rule to be run only for the application's
> dependencies, and not for the application itself. Adding
> 
> inputs: ["application"]
> 
> seems to solve the issue, however for some strange reason (at least,
> strange to me) if the Product using this module is not an application,
> but a shared library, QBS will try to also build the product as an
> application (and this will fail, not last because main() is not
> defined). This is not a big issue, since anyway I'd expect this module
> to be used only for applications, but if possible I'd like to avoid
> hardcoding the input to "application".

Are you sure you haven't added "application" by accident to the output file
tags in your rule or as additionalProductType in your module? Please create
a minimal and complete example showing this behavior and open a bug report
if the problem persists.

> I also tried replacing the `inputs` property with
> 
>inputs: products.type
> 
> but this causes QBS to fail with this error:

I guess you have added "deployed_library" somehow to the product's type in
order to run the rule. This would create a cycle.

> Or maybe my approach is totally off, and it would be better to implement
> dependency deployment as a Product 

A separate product is the usual way:
https://code.qt.io/cgit/qbs/qbs.git/tree/src/shared/bundledqt/bundledqt.qbs
https://github.com/bjorn/tiled/blob/master/dist/distribute.qbs

These are rather pragmatic solutions, but of course not very beautiful.

> (since, ultimately, one would use it
> to obtain a MacOS package, an AppImage or a MSI package?)?
> Then, I suppose, just `inputsFromDependencies: ["application"]` would be
> enough?

Are you sure you want to go that far? I have some doubts that this would be
maintaible. Note that win/mac/linux-deployqt exist for a reason. And since I
supose that >99% of Qbs-managed desktop applications are based upon Qbs, it
might make sense to create a generic wrapper module for those tools.

You are currently only writing about resolving ELF dependencies with ldd.
Sure, ldd is available in every Linux distribution. But what about Windows
(PE)? Which dependency analyzer are you going to use? Windeployqt for
instance comes with its own code (which doesn't compile for Linux targets btw.).

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

Re: [Qbs] Module adding source files to a project

[Richard Weickelt]

> Should the AppImageKit repository (or only the parts needed for building
> the runtime.c file) be imported into the QBS repository (maybe added as
> a git submodule)? Or should we fetch the sources at runtime?

Ideally, I think, the user would just invoke some tool and use a prebuilt
binary and not need to build the run-time from source. If building from
source is required, let the user install AppImageKit somewhere and just
point Qbs to the installation path in a property like shown below.

> Do we have examples of other modules having similar requirements?

Just a module would not be enough. You will need at least one separate
product item for the run-time binary. An appimage module makes sense if you
need common appimage properties in multiple product items, for instance the
AppImageKit install path.

>   I'd like to write a QBS module to package Linux applications into the
> AppImage format. This is a format in which the all application's files
> (and non-trivial dependencies) are packed into a single executable file,
> which, when executed, unpacks the application data by mounting into a
> squashfs filesystem and then executes the application's main binary.
> 
> The trick here is how to create the "loader" part of the binary: the
> AppImage project provides the source code, which consists of a C file
> [1] and all of its dependencies (a slightly modified version of
> libsquashfs, and a few other utility files), but it's not clear to me on
> what would be the best way to bring these files into one's project.

Why do you need to build "runtime" from source? Is a prebuilt version not
shipped together with AppImageKit or at least available here:
https://github.com/AppImage/AppImageKit/releases ?

Presuming that runtime.c is shipped with AppImageKit, there are probably
many ways to implement that. Here is a very naive idea of a product item
that does both: building the run-time binary as well as packaging up the
application bundle:

// AppImage.qbs
CppApplication {
type: [ "application", "appimage.runtime", "appimage.package ]
property string appImageKitInstallPath

Group {
name: "runtime"
prefix: appImageKitInstallPath + "/"
files:  [ "runtime.c" ]
}

// Have a look at
https://code.qt.io/cgit/qbs/qbs.git/tree/src/packages/archive/archive.qbs#n49
// The rule will need to depend on all all installables and
// appimage.runtime and will bake the run-time and the rest together
// into an artifact of type "appimage.package".
// You will specify the depencies later in yourproject.qbs
Rule {}
}

// yourproject.qbs
Project {
CppApplication { name: "yourapp"; /* ... */ }
AppImage {
appImageKitInstallPath: "/path/to/AppImageKit"
Depends { name: "yourapp" }
}
}

Maybe that gives you an idea how and where to start.

You could also create a AppImageRuntime product item and an AppImagePackage
product item to separate the two tasks better. And you could also implement
a module if these items have common properties or you could put all rules
into the module.

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

Re: [Qbs] Understanding installation rules

[Richard Weickelt]

> The reason why I added the "application" tag to the rule is that this
> seemed to force the execution of the rule, with otherwise wouldn't be
> considered.

This is semantically wrong because your rule does not produce an
"application" artifact. I'd suggest to add "desktopfile" to the
additionalProductTypes property of your module:

https://doc.qt.io/qbs/qml-qbslanguageitems-module.html#additionalProductTypes-prop

> I understand that QBS is not running the rule again, because both the
> application and the desktopfile are still available under the build
> directory. But why isn't the desktopfile copied to the installRoot
> again, along with the application?

Does it work with the change suggested above?
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

[Qbs] 1.15 branch created

[Richard Weickelt]

Hi,

Christian has branched off qbs 1.15 yesterday. Scheduled release date for
version 1.15.0 is end of November (together with Qt Creator 4.11) [1]. We
recommend users to try this branch with their projects and report back any
new problems they find. Qt Creator 4.11 beta still ships the Qbs 1.14 branch
and will be updated early next week. Snapshots can then be obtained from [2].

Contributors are requested to push bug fixes and small, zero-risk
improvements to this branch, while features continue to go to master.

Patches currently on gerrit can be moved if they are reasonably close to
finished.

Richard

[1] https://wiki.qt.io/Qt_Creator_Releases
[2] http://download.qt.io/snapshots/qtcreator/4.11/
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] [baremetal] I looking proffesionals faced with Cypress FX2 && IAR

[Richard Weickelt]

> It did not helps, because a problem is somewhere  deeped. E.g. in this code:
> 
> static BOOL ep0_std_descriptor_proc(void)
> {
>     BYTE XDATA *pdesc =
>     (BYTE XDATA *)hid_ep0_std_desc_get();
>     if (pdesc) {
>     SUDPTRH = usb_word_msb_get(pdesc);
>     SUDPTRL = usb_word_lsb_get(pdesc);
>     return TRUE;
>     }
> 
>     return FALSE;
> }
> 
> something wrong with SUDPTRH && SUDPTRL features. It is a HW features of
> this chip which transfer the content of a "standard" descriptors to the HOST
> automatically. I.e. enough to set an address of a descriptor structure to
> the  SUDPTRH and SUDPTRL registers.

I can't see a problem in the assignment as such and since other register
assignments work, it is unlikely a problem with SUDPTRH/L. The access order
is also correct. pdesc is a pointer to the descriptor table. How sure are
you that pdesc points to actual content? Where is the descriptor table
content defined? Where is hid_ep0_std_desc_get() defined?

> Are you know that a many modern chips based on 8051 architecture? Look on
> TI, Cypress and etc. This architecture is more simple than ARM, the ARM it
> not a panacea to all.

I am not saying that I like ARM monoculture. I am working in the TI office
that designed the 8051 2.4 GHz chips btw. The last one was published around
2009 if I am not mistaken and I would be surprised if any customer uses them
in new designs.

I'd be interested to see a "modern" 8051 chip. I didn't want to discourage
you at all. Just looking from a different perspective:

As a company You usually invest in markets where you expect growth in order
to make money and win customers. Winning new customers is much easier in
emerging markets. It is almost impossible in areas where everybody has
settled on certain devices, tools and processes.

Translated to the Qbs cpp module that means: invest in MCUs and toolchains
that you expect to become important in the next years and where you expect
to win users. It is much more likely that anybody starts a project with
brand-new chips. This is the time where companies might evaluate tooling,
play around with different options and so on. If you then have an appealing
off-the-shelf solution ready, that also developers time, it is more likely
to become a success.

That being said: RISC-V might be a thing. Multi-core MCUs are already a
thing. Building firmware for multi-processor devices with a heterogenous ABI
or configuration is quite challening for GNU Make based build systems. And
doing that in clicky-clicky IDEs is IMO not scalable. This is an area where
Qbs excels and it might be worth to invest. For instance by finishing Qbs'
half-way implemented multiplex facilities.

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

Re: [Qbs] Session at Qt Contributor Summit next month?

[Richard Weickelt]

Hi Kai,

thanks for the heads-up.

> Nov 19-21th 2019 Qt contributors gather in Berlin to discuss the state of
> the project, make plans and sometimes also do decisions 😉 I'm wondering
> whether there's interest also for a Qbs session? So far nobody registered
> one ...

Since Qbs will not become Qt's next build system, I would guess that the
target audience of this summit wouldn't be interested in Qbs at all. Such a
session might make more sense at a world summit and would probably have
promition character like what Jake did. How great was the interest in
2016/2017 - do you know?

My personal motivation to travel in the middle of a week without being paid
is 0.

But I would be interested to know (and that's somewhat off-topic), if there
is any other project under the Qt Project umbrella that is not directly
driven by the Qt Company, but by the community.

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

Re: [Qbs] [baremetal] I looking proffesionals faced with Cypress FX2 && IAR

[Richard Weickelt]

Hi,

> Currently it does work with Keil C51 compiler && SDCC compiler. But, it does> 
> not work with an IAR 8051 compiler.

I guess you do not have JTAG access to this device and can step-debug. But
it looks like you have GPIOs that you could access with a logic analyzer.

> I don't know why, but the USB enumeration fails, the OS can't fetch the USB
> descriptors from the FW. e.g. at attempt to fetch the USB "Device
> Descriptor", the OS receives a zero data.

I haven't reviewed Your code, but here are some ideas:
- interrupt tables not correctly initialized
- missing volatile qualifier in variables shared between task and interrupt
context. This is a common mistake, especially when one side uses this
variable in a loop (task waiting for a flag) and never observes a change
because the variable value is kept in a register.

> Maybe, someone can help me? Because I have not ideas why it does not work
> with IAR. 

Possible strategies when you cannot debug with JTAG:
- use a GPIO and a logic analyzer to output serialized data at certain
checkmarks to see whether the program works correctly.
- decompose your application, make sure that the peripherals are working one
after another

> PS: A google has not any mention or example at using this chip && IAR 
> compiler.

And that makes me wonder if you are the only person on the planet trying to
do this. This looks like a hobby project. Is IAR even used among hobbyists?

If you want to show-case multi-toolchain development with Qbs, why 8051? I
doubt that any company uses 8051 for new projects. At least, companies would
build upon a large legacy codebase and infrastructure (we have done this for
30 years...) . Why should anybody invest time in using Qbs on 8051?

However, your project looks exotic enough to be fun :)

Richard
___
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!!

[Richard Weickelt]

> What is all this talk about 1.14.1? 1.14.0 has not even been released yet. We
> expect it shortly.

1. Qbs shipped with QtCreator 4.10.0 prints version "1.14.0" although Qbs 
1.140.0 was not release yet. A minor release of QtCreator used to ship a minor 
release of Qbs.

2. You have announced Qbs 1.14.0 release for end of July which didn't happen, 
probably because QtCreator 4.10 release was delayed. 
https://lists.qt-project.org/pipermail/qbs/2019-June/002439.html

3. You did neither communicate above exception nor did you respond to questions 
and this opened up the room for speculation.

For the benefit of the Qbs project it would help if you could more 
(pro-)actively communicate Qbs releases. As soon as Qbs 1.14.0 is out it would 
be great to communicate when 1.15 can be expected and stick to the plan. If 
there are deviations, please communicate. If you are unsure whether you will do 
the 1.15.0 release at all, please communicate that as well. That is the only 
chance for the community to step up and take over responsibilities.

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

Re: [Qbs] Ideas inspired by pro2cmake.py

[Richard Weickelt]

> On Fri, Sep 20, 2019 at 10:14:54PM +0800, Vincent Hui wrote:
>> It seems that it is possible to develop pro2qbs.py, [...]
>>
> patches for https://bugreports.qt.io/browse/QBS-586 welcome. ;)

Indeed, that would be a great contribution, Vincent.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

[Qbs] Use compiler flags file generated by a rule

[Richard Weickelt]

Hi,

I want to integrate a generator tool into a Qbs build flow. This tool is very 
slow and produces a bunch of .h/.c files and a "compiler.opt" file with some 
compiler flags. I need to use these flags to build the current product and also 
export them to dependent products. I guess this is not possible with Qbs 
because all flags in the build graph need to be determined before the actual 
build starts. Or is it possible to inject flags into the build graph during the 
build?

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

Re: [Qbs] run test executables outside QBS environment

[Richard Weickelt]

> I'm looking for a way to run test executables - created by QBS - outside
> of a QBS environment. To me this looks problematic since you can define
> runVars inside QBS that are not known outside of QBS.
> 
> Any idea how to handle this?

An idea, not a solution. You could generate a shell wrapper script together
with each executable where you export all relevant variables. Then you call
the wrapper script instead of the executable, or you would source the
wrapper script.

I guess you are most interested in dynamic library resolution which is
handled by the environment variables:

- LD_LIBRARY_PATH on Linux
- DYLD_LIBRARY_PATH on MacOs
- PATH on Windows

For how to find out all relevant library paths for an application product,
you can get an inspiration from
https://code.qt.io/cgit/qbs/qbs.git/tree/share/qbs/modules/cpp/setuprunenv.js
You might even use these functions as they are.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Generating a c++ class with Q_OBJECT

[Richard Weickelt]

> CppApplication {
> name: "test"
> cpp.includePaths: sourceDirectory
> files: [
> "main.cpp",
> ]
> Depends { name: "Qt"; submodules: ["core", "xml"] }
> Depends { name: "kdsoap" }
> Rule {
> multiplex: true
> Artifact { filePath: "wsdl.cpp"; fileTags: "cpp" }
> Artifact { filePath: "wsdl.h"; fileTags: "cpp" }
> prepare: {
> var file = product.sourceDirectory +
> "/wsdl/WsAnnuaire.wsdl";
> var cmd = new Command("kdwsdl2cpp", ["-both", "wsdl",
> file]);
> cmd.description = "generating " + outputs;
> cmd.workingDirectory = product.buildDirectory;
> return cmd;
> }
> }
> }
> 
> Adding the second artifact makes qbs call moc on the wsdl.h and generates
> the qt.headers/wsdl.moc file.
> But how can I add this file to the link?

What do you mean by "link"? That the resulting .cpp file is compiled and
linked into your application? AFAIK, this should happen automatically. But
your rule above does not look kosher to me:

1. Your rule should specify a filetag as input. That might be "wsdl".
Otherwise Qbs will not (re-)run the rule upon changes in the wsdl file.

2. Consider to add a FileTagger for "wsdl" files or at least, put the wsdl
file into a group item and assign the "wsdl" filetag.

3. Why do you set multiplex true? Can the tool handle multiple wsdl input
files and creates one single large .h and .cpp file? Otherwise, consider to
set it to false (default) and generate one cpp+hpp file per wsdl file input.

4. I think you should use "hpp" as filetag for the wsdl header artifact.

5. Consider to add the output directory of the rule to cpp.includePaths if
you want to easily include them into your source files, for instance via
#include .

7. If you are going to use this generator in multiple products, consider to
write a module.
https://doc-snapshots.qt.io/qbs-master/custom-modules.html#custom-modules

The documentation about writing rules has recently been updated. Have a look
at:
https://doc-snapshots.qt.io/qbs-master/qml-qbslanguageitems-rule.html#a-complete-example

Does this maybe solve your problem?

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

Re: [Qbs] Will Qbs 1.15 be developed and released by The Qt company?

[Richard Weickelt]

> Thanks to The Qt company and all Qbs contributors, we know Qbs 1.14 release
> is around the corner.
> 
> I think it should be the time to let Qbs contributors and users to know
> more the future of Qbs.
> 
> Will Qbs 1.15 be developed and released by The Qt company?

If the Qt Company follows the current release cadence, then Qbs 1.15 might
be released together with QtCreator 4.11.
https://codereview.qt-project.org/c/qbs/qbs/+/271285 but whether that
happens, is unclear. There is nobody who has comitted to do so. That might
be one reason why you didn't get an answer to your question.

Further development of Qbs follows
https://wiki.qt.io/The_Qt_Governance_Model#Decision-making_process at the
moment. There is no roadmap because Qbs is no longer a Qt Company product
and all new features are currently contributed by external persons, probably
in their spare time.

Do you have any suggestion? Is there anything you would like to commit to?

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

Re: [Qbs] Define the link order without an explicit dependency

[Richard Weickelt]

> Why not have a central property that controls these dependencies everywhere?
> Can be done without redundant code via a proxy product:
> 
> Product {
> name: "A"
> property string libAVariant: "a1"
> Export {
> Depends { name: "A-1"; condition: product.libAVariant === "a1" }
> Depends { name: "A-2"; condition: product.libAVariant === "a2" }
> }
> }
> 
> And just depend on A everywhere. The libAVariant property could also be in a 
> Project item or some helper module.

Thanks for your reply. You are suggesting to switch libAVariant globally and
I can see how that would work.

My project consists of multiple products where some have a dependency on
libAVariant "a1" whereas others have a dependency on "a2". If I apply your
suggestion, I would only be able to build either apps depending on "a1" or
"a2" at a time, but not both.

I was able to work around the problem by linking against the whole library
a1 or a2 in the app:

Product {
name: "a-headers"
}

StaticLibrary {
name: "a1"
Depends { name: "a-headers" }
}

StaticLibrary {
name: "a2"
Depends { name: "a-headers" }
}
StaticLibrary {
name: "b"
Depends { name: "a-headers" }
}

Application {
name: "someapp-with-a1"
Depends { name: "a1"; cpp.linkWholeArchive }
Depends { name: "b" }
}

Application {
name: "someapp-with-a2"
Depends { name: "a2"; cpp.linkWholeArchive }
Depends { name: "b" }
}

That way the link order doesn't matter anymore. Not 100% optimal, but it works.

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

[Qbs] Define the link order without an explicit dependency

[Richard Weickelt]

Hello,

I have the following scenario:

Product {
name: "some-headers"
}

// Implementations of some-headers
// A-1 and A-2 define the same symbols and are mutually exclusive.
// An application product can only depend on one of them at a time
StaticLibrary {
name: "A-1"
Depends { name: "some-headers" }
}
StaticLibrary {
name: "A-2"
Depends { name: "some-headers" }
}

// Can be linked to both, A-1/2
// But it must always appear after A-1/2 on the linker command line
// of a dependent application.
StaticLibrary {
name: "B"

// Not sufficient to make B link after A-1/2
Depends { name: "some-headers" }

// Can not do that because it would make "app" link to both
// A-1 and A-2 to app.
// Depends { name: "A-1" }
// Depends { name: "A-2" }
}

CppApplication {
name: "app"

// Selects one of A-1 or A-2, but never both
Depends { name: "A-1" }
Depends { name: "B" }
}

Since I don't explicitly specify a dependency between A-1/2 and B, the link
order is undefined, i.e. B may appear before A-1/2. Is there any way to tell
Qbs that B must always appear after A-1/2 in the library list of app?

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

Re: [Qbs] How to download and uncompress files with Qbs directly?

[Richard Weickelt]

> Do you think I can use Network Access API of Qt to download files and
> QByteArray::qUncompress to uncompress files in Qbs code?

Qbs doesn't provide access to these API. And even if it would, they are not
sufficient to achieve what you want. I think you are better off using
external tools for downloading and extracting your dependencies. You might
still invoke them via a Probe on project level.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] How to download and uncompress files with Qbs directly?

[Richard Weickelt]

>> Another automated and platform-independent library interface would be Conan
>> or vcpgkg. Have you searched for packages on bintray?
>> 
> these are some of the services that would need wrapping.

Why would you wrap these tools with Qbs and not use them side-by-side or - the 
other way round - use them as a wrapper for Qbs? It is my understanding that 
configuration/dependency/package management sits on top of build automation. 
Conan provides a recipe containing versions and configuration options for each 
dependency. It downloads all dependencies and generates something that can be 
consumed by your build system. In case of Qbs, see 
https://docs.conan.io/en/latest/integrations/build_system/qbs.html. That 
defines a sharp boundary between build automation and 
configuration/dependency/package management. I don't say that Conan is 
particularly beautiful, but I think it's a reasonable approach.

I haven't used vcpkg. Is it different?

>> If all that is not an option, then you might implement your own download &
>> install solution.
>> 
> i would recommend that "your own" be something contributable upstream,
> to get https://bugreports.qt.io/browse/QBS-62 resolved.
> 
> note that a key feature for configuration management is the ability to
> pin the sources and versions of modules, which is why the "grown-ups"
> from the java world (at least maven and bazel, and i presume also
> gradle) support it. conversely, linux distributors *hate* it - they want
> abstract package names and ranges of acceptable versions, based on
> binary compatibility promises. a good implementation would permit strict
> and relaxed operation with the same project files, and per-module
> overrides from the outside to support selective unbundling (see also
> QBS-61).

Given the current manpower behind Qbs, I have serious doubts that this is going 
to happen any time soon.

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

Re: [Qbs] How to download and uncompress files with Qbs directly?

[Richard Weickelt]

> Does Qbs support downloading and uncompressing files directly?

Not directly, because it is a build automation tool and not a package manager.

> For example, I need to use Eigen 3.3.7
>  in my project, and
> install it in the build folders of my projects. How to achieve my goal?

If you have a pkg-config file for Your library, then Qbs can generate a
module on-the-fly. See https://doc.qt.io/qbs/module-providers.html

Another automated and platform-independent library interface would be Conan
or vpgkg. Have you searched for packages on bintray?

If all that is not an option, then you might implement your own download &
install solution. You could potentially abuse Qbs probes for this.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] [RFC] Add a clang-format config file to qbs repo

[Richard Weickelt]

Nice,

is there a possibility that the Qt Sanity Bot will review the style and give
feedback immediately?
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] A simple project that copy an executable does not work

[Richard Weickelt]

> No, this is not possible. The reason is that in common case those products
> (applications, libraries) will diverge in some way. For example, you might
> want to use different resources - icons (you probably do not want to name
> them icon1.png and icon2.png, right?), .desktop entires on Linux, plist
> files on Mac…
> 
> However, you might want to share some properties among those applications -
> that can be achieved via inheritance - you inherit the CppApplication item
> in a file, say, MyApplication.qbs, specify common properties (cpp.cxxFlags,
> cpp.cxxLanguageVersion, etc…) and then instantiate MyApplication and only
> specify only what’s different (files: «main1.cpp» and files: «main2.cpp» in
> your case). That way you don’t need to write all that boilerplate code over
> and over again.

Some links to illustrate what Ivan just explained:

https://doc.qt.io/qbs/custom-modules.html#making-qbs-aware-of-custom-modules-and-items

A customized Product item:
https://code.qt.io/cgit/qbs/qbs.git/tree/src/app/qbs/qbs.qbs

The related base item:
https://code.qt.io/cgit/qbs/qbs.git/tree/qbs-resources/imports/QbsApp.qbs

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

Re: [Qbs] A simple project that copy an executable does not work

[Richard Weickelt]

> I created a simple project to copy an executable generated by
> CppApplication. However the executable is not copied.
> 
> I cannot figure out why? Can anyone tell me why?

Please read
https://doc.qt.io/qbs/qml-qbslanguageitems-rule.html#rules-and-product-types

Your rule is not executed because the product type is "application" and
there is most likely no other product or rule that depends on an .out file.

You should assign a file tag to the rule's output artifact and add this file
tag to the product type. Something like this:

CppApplication {
type: [ "outfile"]
// ...
Rule {
Artifact {
filePath: input.fileName + ".out"
fileTags: [ "outfile" ]
}
// ...
}
}

Why do you want to copy an application executable into an .out file? That
seems pointless. Do you maybe want to change the executable suffix? There is
an undocumented property cpp.executableSuffix which you could try:

CppApplication {
cpp.executableSuffix: ".out"
// ...
}

I don't know why it is undocumented. Maybe some linkers do not allow to
change the suffix.


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

Re: [Qbs] Is there a feature similar with cmake option?

[Richard Weickelt]

>> Cmake options can be overridden by CMakeCache.txt files inside build
>> folders. Is there similar feature in qbs?
> 
> No, and it sounds like a horrible idea.

Regardless of the CMake inherent beauty. If you (Victor) want to have a
profound answer to your question, you should explain what CMakeCache.txt is
used for. It would be also helpful if you come up with an understandable
example of your use-case.

I found this explanation:
https://stackoverflow.com/questions/42160117/what-is-cmakecache-txt-and-why-it-overrides-my-variables

And it sounds like CMakeCache.txt is used to prevent from typing a CMake
command line with lots of -D. Is that correct? There is no direct
equivalent in Qbs.

You can override project, product and module options on command line:
https://doc-snapshots.qt.io/qbs/cli-build.html#parameters

Nothing stops you from putting your custom overrides into a text file and
then insert them right in place:

# options.txt
modules.cpp.optimization:fast project.myCoolFeatureEnabled:true

# my-qbs-invocation-script.sh
qbs build $(cat options.txt)

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

Re: [Qbs] How to add -pthread option into projects? a bug in qbs ?

[Richard Weickelt]

> My next question is how to fix the bug in conan qbs generator? driverFlags
> does not exist in conan qbs generator.

You can either 

1. Wait for this fix to be integrated:
https://github.com/conan-io/conan/pull/5452
2. Modify the Qbs generator in your Conan installation
3. Implement your own Qbs generator into the project you want to build.

The cpp_info object model of Conan is very limited. Conan does not know about
driver flags and I doubt it will any time soon. So there is not much we can do
about that. I don't think it is dangerous to put -pthread into cpp.cxxFlags
although it is not entirely correct either. You can try to add -pthread to
cpp.driverFlags in your product. That might result in doubling -pthread on the
command line since it is applied by cxxFlags as well. If the compiler (g++?)
complains, you can also use cpp.driverLinker flags instead. This will apply
-pthread only to the invocation of the linker driver. The compiler is then
covered by cpp.cxxFlags provided by the dependency.

Richard

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

Re: [Qbs] How to add -pthread option into projects? a bug in qbs ?

[Richard Weickelt]

> How to add -pthread option into projects?
> ...
>     cpp.cppFlags: ["-pthread"]

Try using cpp.cxxFlags or cpp.driverFlags instead. cpp.cppFlags has a
different meaning. See
https://doc.qt.io/qbs/qml-qbsmodules-cpp.html#cppFlags-prop

> I encountered this error too when use qbs file generated by conan to add
> dependency of opencv 4.0.1 to my project.

This is a bug in the Conan Qbs generator which still exports compiler
options to cpp.cppFlags. See https://github.com/conan-io/conan/issues/4730

If you find the time to fix
https://github.com/conan-io/conan/blob/develop/conans/client/generators/qbs.py
that would be awesome. It's just two letters.

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

Re: [Qbs] How to add -pthread option into projects? a bug in qbs ?

[Richard Weickelt]

> How to add -pthread option into projects?
> ...
>     cpp.cppFlags: ["-pthread"]

Try using cpp.cxxFlags or cpp.driverFlags instead. cpp.cppFlags has a
different meaning. See
https://doc.qt.io/qbs/qml-qbsmodules-cpp.html#cppFlags-prop

> I encountered this error too when use qbs file generated by conan to add
> dependency of opencv 4.0.1 to my project.

This is a bug in the Conan Qbs generator which still exports compiler
options to cpp.cppFlags. See https://github.com/conan-io/conan/issues/4730

If you find the time to fix
https://github.com/conan-io/conan/blob/develop/conans/client/generators/qbs.py
that would be awesome. It's just two letters.

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

Re: [Qbs] How do I use Parameter property in a module itself?

[Richard Weickelt]

> Is it true that all module properties should be allowed to be set per-file?
> 
>  Product {
>   Depends { name: "mymodule"; }
>   mymodule.useFeature: true // enable some probes here, do heavy checks
> 
>   Group { files: «file»;  mymodule.useFeature: false; } // does nothing, 
> all checks are already done
>   }
> 
> What worse, this won’t work at all:
> 
>  Product {
>   Depends { name: "mymodule"; }
>   Group { files: «file»;  mymodule.useFeature: true; } // ooops
>   }
> 

This is how I understand the documentation:
Yes module properties can be specified on file level (in a group), but:
- probes are evaluated only once for each product and in product scope
- the probe would see the module properties set for a product
- the probe would not see module properties set for a group
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] How do I use Parameter property in a module itself?

[Richard Weickelt]

Ivan,

Do you actually want to achieve this?

Module {
property bool useFeature: false

Probes.BinaryProbe {
condition: useFeature
}
}

Product {
Depends { name: "mymodule"; }
mymodule.useFeature: true
}

The Parameter item, as far as I understand it, makes only sense if you have
- 2 products A and B
- B depends on A and on mymodule
- in the context of B you want to control, how a module "mymodule"
  handles A

You wouldn't use it to just parameterize "mymodule", because that can be
achieved with plain properties.

The probably best explanation so far of the Parameter item can be found in
the following blog post:
https://blog.qt.io/blog/2017/09/05/qbs-1-9-released/ I realize that the
reference documentation of the Parameter item is insufficient and the
example in the module documentation could be more sensible.

Richard
___
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?

[Richard Weickelt]

> Oh yeah, it has been an unsatisfying surprise that default installation
> prefix changed from empty string to "usr/local/" on Linux. All builds
> are broken, all scripts working on the results are broken. Not
> hardcoding is not an option when it comes to CI integration etc.
> 
> Next time I will be happy if such a change is announced in capital
> letters.

This was also an unpleasant surprise for me. Note that
https://doc.qt.io/qbs/qml-qbsmodules-qbs.html#installPrefix-prop does not
reflect this change. Thus, instead of going over the docs, I'd rather like
to set installPrefix back to undefined on all platforms for Qbs 1.13.1.

Anything that speaks against that?

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

Re: [Qbs] Future of Qbs

[Richard Weickelt]

Lars or anybody else from The QtCompany,

I would like to follow up on this topic.

> I think this also gives us a chance to do a proper handover to the
> community if we can find some people who are interested in helping with
> maintaining the technology. From The Qt Company’s perspective, we’d be
> glad to help with this transition effort. Let’s try to find out, what’s
> needed to make such a handover a success

Right now the Qt Company holds the ownership of the code base and all
contributions have to pass the obligatory Qt CLA. The Qt Company has also
clearly communicated that they would not support Qbs beyond 2019. That makes
it very difficult to convince other parties to invest in it.

It would be good if the Qbs project would be transferred to a widely
trusted, non-personal, non-profit organization. The Linux foundation for
instance might be a candidate we could try. Such an organization as backup
would help the Qbs project to
- gain trust among (industrial) customers
- find sponsors
- to get structural, organizational and maybe also technical support

Thus, would the Qt Company be willing to:
1. transferring ownership of the code base and the brand Qbs to
   a non-personal non-profit entity? If yes, in which time frame?
2. re-license Qbs under a permissive open source license?
   Is Qbs even subjected to the agreement with the KDE Free Qt Foundation?
3. Sponsor the Qbs project, for instance by continue to pay for the domain
   qbs.io or by allowing Qt engineers to spend (limited) time on keeping
   Qbs working in QtCreator, doing code reviews to some extend in their
   work time?
4. provide technical infrastructure like JIRA, gerrit, hosting,
   at least for a transition period of 2 years even though ownership
   has been transferred?

Thank you for your reply.
Best regards
Richard Weickelt
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Richard Weickelt]

> Maybe then, do we can take the JS engine from the Qt declarative? As
> a simple way... No? Let's define a first concrete tasks, what do we
> need to do at all? :)

1.  Read and understand https://bugreports.qt.io/browse/QBS-913
2.  Analyse and understand how Qbs uses the JS engine from QtScript
3.  Understand what infrastructure is missing in QtDeclarative
4a. Implement the missing pieces and get them into QtDeclarative
4b. Implement the missing pieces and put them into Qbs
4c. Go with a different JS engine


As Oswald already said: it's probably less effort to carry on QtScript as a 
submodule and port it over to Qt6. Personally, I would prefer 4a as it would 
allow using QML as DSL for similar applications like Qbs. Feel free to come up 
with a proof of concept.

___
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?

[Richard Weickelt]

Tobias,

I think it is of utmost importance for the survival of Qbs that it is fully
supported by an IDE like QtCreator.

> Note that this is about the build system used to *build Qt Creator with*, not
> about *build systems supported by Qt Creator*. I would personally like to keep
> qbs supported as a build system for projects in Qt Creator for as long as it 
> is
> feasible.

What would yo define as the minimum criteria for keeping Qbs supported in Qt
Creator?

> The challenge will be Qt 6: Creator will use Qt 6 ASAP and since qbs is linked
> into Creator, that will also need to be ported to Qt 6 to stay feasible.

Do you already have an idea when QtCreator will switch to Qt 6? Given the
current release plan https://wiki.qt.io/Qt5Releasing, I expect the first
release of Qt6 to happen around November 2020.

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

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Richard Weickelt]

>> However, will this help to get new developers? Right now, there are not that
>> many contributors.
> 
> I agree, how much money do you want to raise? And what for?
> For now Qbs can use Qt (company/project) infra, so there's no need to
> manage an infra.

The Qt Company pays for qt.io. We can ask them to sponsor the domain also in 
the future, but we cannot expect it.

If we had fee-lancing contributors, then it might make sense to set up a bounty 
system. I also find models like this https://www.patreon.com/bjorn interesting. 
I guess that spare-time contributors have a different motivation though.

What is IMO more important is, to turn qbs.io into an attractive landing page. 
It should become more clear, that Qbs is no longer a The Qt Company project. 
Might be worth to pay a web designer to come up with a professional looking.  
Any volunteers? https://bugreports.qt.io/browse/QBS-1341

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

Re: [Qbs] Donation to QBS developers/maintainers/contributes

[Richard Weickelt]

> If I am right, one urgent task is to remove the dependency of Qt Script.

I don't think it's urgent. It might not even be necessary given that Qbs won't 
be Qt's next build system and won't have to be bootstrapped. But if you have 
good ideas, feel free to discuss in https://bugreports.qt.io/browse/QBS-913

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

Re: [Qbs] Any novice tickets

[Richard Weickelt]

 
> Meanwhile, I get another question… I think, I already asked it, but still. Is 
> the magic behind config parameter documented somewhere?

Have you looked at 
https://doc.qt.io/qbs/cli-build.html#parameters ?
This was updated only recently.
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Qbs status update - looking for a maintainer

[Richard Weickelt]

Hello Tino,

thanks for the update.

> In addition to contributors, the Qbs project would need a new maintainer.
> Christian Kandeler has done a great job, but his effort is needed in other
> projects as well. We are looking for a new maintainer, who has a good
> understanding of Qbs and will take responsibility for tasks such as
> continuous integration and release management. Suggestions are welcome.

Will Leena still be available for documentation reviews?

Christian, are you planning to step down as a maintainer in 2019 or will you
make that dependent on the amount of external contribution? Right now, the
amount of contribution doesn't look overwhelming.

Nevertheless, release management and testing should become entirely public
and not happen behind closed doors. I noticed that the Qt Company is running
an internal gitlab at https://git.qt.io/. Does that include gitlab CI? Can
it be connected to gerrit?

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

Re: [Qbs] bare-metal: Need help with adding of SDCC compiler

[Richard Weickelt]

 
> I have planns to add support for SDCC [1] compiler to QBS/QtC for 
> bare-metal devices.
> 
> But problem is that this compiler supports multiple different arcitectures:

Unlike your IAR implementation, I wouldn't probe the compiler and guess 
qbs.architecture. Instead I would expect the user to set qbs.architecture in 
the profile or in the product explicitly. I could be wrong, but I think that 
was the approach for all toolchains before probes were invented.
 
> c:\SDCC\bin>sdcc -v
> SDCC : 
> mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8
>  
> 3.8.0 #10562 (MINGW32)
> published under GNU General Public License (GPL)
> 
> The target architecture is specified trough the flag -m... So, in 
> different cases we wil get a different predefined macroses, e.g:
> 
> === MCS51 ===
> 
> c:\SDCC\bin>sdcc -dM -E -mmcs51 e:\git\ng\git\123\qbs-git\main.c
> #define __SDCC_mcs51 1
> #define __STDC_VERSION__ 201112L
> #define __STDC_HOSTED__ 0
> #define __STDC_UTF_16__ 1
> #define __SDCC_VERSION_MINOR 8
> #define __SDCC_MODEL_SMALL 1
> #define __STDC_ISO_10646__ 201409L
> #define __SDCC_VERSION_PATCH 0
> #define SDCC 380
> #define __SDCC_FLOAT_REENT 1
> #define __SDCC_VERSION_MAJOR 3
> #define __STDC_NO_VLA__ 1
> #define __SDCC 3_8_0
> #define __STDC_UTF_32__ 1
> #define __STDC_NO_THREADS__ 1
> #define __SDCC_CHAR_UNSIGNED 1
> #define __STDC_NO_ATOMICS__ 1
> #define __STDC__ 1
> #define __SDCC_REVISION 10562
> #define __STDC_NO_COMPLEX__ 1
> 
> === Z80 ===
> 
> c:\SDCC\bin>sdcc -dM -E -mz80 e:\git\ng\git\123\qbs-git\main.c
> #define __STDC_VERSION__ 201112L
> #define __SDCC_INT_LONG_REENT 1
> #define __STDC_HOSTED__ 0
> #define __STDC_UTF_16__ 1
> #define __SDCC_VERSION_MINOR 8
> #define __SDCC_z80 1
> #define __STDC_ISO_10646__ 201409L
> #define __SDCC_VERSION_PATCH 0
> #define __SDCC_FLOAT_REENT 1
> #define __SDCC_VERSION_MAJOR 3
> #define __STDC_NO_VLA__ 1
> #define __SDCC 3_8_0
> #define __STDC_UTF_32__ 1
> #define __STDC_NO_THREADS__ 1
> #define __SDCC_CHAR_UNSIGNED 1
> #define __STDC_NO_ATOMICS__ 1
> #define __SDCC_STACK_AUTO 1
> #define __STDC__ 1
> #define __SDCC_REVISION 10562
> #define __STDC_NO_COMPLEX__ 1
> 
> and etc.
> 
> So, it is problematic to define a compiler ABI and etc...
> 
> Has anybody any suggestions how to solve this? Is any similar cases in 
> QtC/QBS?
> 
> Because I have not ideas...
> 
> BR, Denis
> 
> 
> [1] http://sdcc.sourceforge.net/
> 
>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Unexpected behavior of MSVC generator

[Richard Weickelt]

Denis,

> > What’s the point of implementing a rule for cpp files directly in the 
> solution and not implementing it for other cases? I don’t see any use cases.
> 
> I'm don't understand a bit, what do you mean here?

I think your view on the build process is too narrow. If all you care about is
the conversion of C/C++ sources to object files to application binary, then it
could make sense to produce native build files for your favorite IDE. This is
all what proprietary IDEs with their little proprietary "build automation
system" like IAR are usually capable of. But as soon as you want to

- integrate custom tools in your build process, for instance code generators
  (you mentioned already Qt moc)
- build additional assests, like documentation
- combine libraries and applications in a single build
- parameterize parts of your project

it becomes painful. Even for IAR users, additional code generators are not
uncommon. The IAR IDE gives you the option to define one pre-build, one post-
build action and ONE additional rule for a SINGLE tool. That might be
sufficient in some simple cases, but as soon as you want to do more, you have
to work around the IDE, for instance by invoking an external build tool.

With the assumption that such cases are very common, it doesn't make sense to
generate native build files at all. It is then often better and easier to let
Qbs run the build process. I guess, this is what Ivan wanted to tell you.

> UPD: I'm ask all this question, because I'm doubt: is it makes sense 
> tries to implement the generators (to spent a time) for a "bare-metal" 
> stuff... e.g. to generate the projects for IAR, Keil, Atmel Studio and 
> etc? Or QBS is dead, and we need to make tries to use CMake for that 
> cases (but I'm don't know and don't like CMake)? It is a main dilemma! :)

If you are using IAR then you probably appreciate the performant debugger and
its ability to debug even highly optimized code. You are probably also used to
IAR's editor and you can't live without it. Fair enough, but for that you
don't need its native build tool, really. All you need is a project file
generator that sets correct source files, defines, include paths and the
application binary file path so that the IDE can understand it, invokes the
debugger correctly and resolves code locations while debugging.

I think the same applies to the other IDEs you mentioned. Whether it makes
sense to implement a project file generator is a different question. It could
make sense if you are bound to one of those IDEs, but you want to build
projects of higher complexity than what they can handle.

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

Re: [Qbs] tst_blackbox-qt fails

[Richard Weickelt]

Christian,

>> This is how I build and test now:
>>
>> qbs build profile:qt
>> qbs run -p qbs_app profile:qt -- setup-toolchains --detect
>> qbs run -p qbs_app profile:qt -- setup-qt
>> /usr/local/Qt/5.9.7/gcc_64/bin/qmake qt
>> QBS_AUTOTEST_PROFILE=qt qbs build -p autotest-runner profile:qt
>>
>> Is this how it is supposed to be done?
> > Looks fine to me. For extra safety, e.g. if simultaneous execution with
> other qbs instances is required, one would also pass a dedicated
> --settings-path, as to have truly unique profiles for the respective
> run.
I have to bring this up again because I noticed that autotest-runner above
does only work if I export QBS_AUTOTEST_PROFILE to the system environment.
Exporting it in the current user session as shown above, does not work. The
only way I was able to do it was, to override project.autotestWrapper with a
custom script that exports QBS_AUTOTEST_PROFILE. But isn't that a little
awkward? Therefore I would like to know:

1. Is that the way how developers are supposed to inject profiles into the
   autotest-runner product?
2. How are you doing it? Could you publish your Jenkins scripts?
3. How about adding a property "runEnvironment" to QbsAutotest that would
   allow to set the profile on the command line when building
   autotest-runner? Those variables would be appended to
   qbs.commonRunEnvironment in the product.

Thank you very much
Richard
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Including project files matching git submodules

[Richard Weickelt]

> But I have one more question: Is Project { references: [...] } the only way
> to include other files, apart from defining new modules?

Please specify "include other files". Did you want to say "include other
.qbs files into a project"?

If yes, then in addition to the 2 ways you mentioned, you could also extend
a Qbs language item and instanciate that somewhere in your project. See
http://doc.qt.io/qbs/custom-modules.html#custom-items and see
http://doc.qt.io/qbs/qbsconvenienceitems-qmlmodule.html for a list of
derived Product/Project items that are shipped with Qbs.

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

[Qbs] Meta-modules in Qbs

[Richard Weickelt]

Hi,

this patch introduces meta-modules in Qbs:
https://codereview.qt-project.org/#/c/249274/1

> If a dependency is not found, we now search for a matching meta-module
> that can generate one for us. We also provide a generic fall-back
> meta-module which uses pkg-config to locate the dependency (but could be
> extended to incorporate other methods in the future). This is the most
> important part of this change for practical purposes, as it makes
> hundreds of popular libraries available for use in qbs projects without
> users having to write any boilerplate code. In a future patch, a
> meta-module could also be used to implement the functionality of the
> qtprofilesetup library, relieving users of the need to create a profile
> for building Qt applications.

This is an important conceptional addition and more people might be
interested to review and provide feedback.

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

Re: [Qbs] tst_blackbox-qt fails

[Richard Weickelt]

Christian,

>> I tried to build Qbs from source and to run the autotests on Debian stretch
>> with Qt 5.9.7 and 5.12.0. After creating a Qt profile (with the built Qbs)
>> and setting the undocumented QBS_AUTOTEST_PROFILE variable I still see some
>> tests failing in tst_blackbox-qt (see log below).
>
> I strongly suspect that you did not run the autotests with the exact same
build that you called setup-qt with. Please double-check.

Thanks, that was it. I wasn't aware that Qbs stores profiles in different
folders for each Qbs version. I assumed all Qbs versions share a single
folder with profiles.

This is how I build and test now:

qbs build profile:qt
qbs run -p qbs_app profile:qt -- setup-toolchains --detect
qbs run -p qbs_app profile:qt -- setup-qt
/usr/local/Qt/5.9.7/gcc_64/bin/qmake qt
QBS_AUTOTEST_PROFILE=qt qbs build -p autotest-runner profile:qt

Is this how it is supposed to be done?

>> I need some guidance how to properly setup the autotests. In addition, I
>> would like to know how The Qt Company is running Qbs regression tests today
>> on which platforms and when.
>
> This is currently done on a local Jenkins-based CI. Tests run on Linux (32
and 64 bit), macOS (different versions) and Windows. On Windows, MSVC and
mingw are tested. For the Qt autotests, we also test against a static Qt
installation on Windows.

Is this visible outside your company?
How could external contributors leverage that infrastructure? E.g. how could
they invoke tests and see the results?
Would it be possible to integrate that into gerrit? And if yes, would you do it?

>> The page at
>> http://doc.qt.io/qbs/building-qbs.html does not talk about autotests and the
>> docker images are outdated. Thus I assume that the information on this page
>> is not used.
>
> I don't know what you mean by that.

1. The page is titled "Building Qbs" but doesn't explain how to run
autotests and the requirements on the environment. If it was explained I
wouldn't have asked above.

2. It is not possible to build and test the Qbs master branch with the
provided Docker images without issues. They come with Qt 5.9.3 and Qbs 1.9.1.

2.1 Building with Qbs fails:

docker pull qbsbuild/qbsdev:stretch
docker run -it -v $PWD:/qbs -w /qbs qbsbuild/qbsdev:stretch

# In the docker shell
qbs setup-toolchains --detect
qbs setup-qt /usr/local/Qt/5.9.3/gcc_64/bin/qmake qt
qbs build profile:qt

No build graph exists yet for this configuration.
Resolving project for configuration default
ERROR: /qbs/tests/auto/blackbox/blackbox-joblimits.qbs:3:1 Errors in product
'tst_blackbox-joblimits':
/qbs/qbs-resources/modules/qbsbuildconfig/qbsbuildconfig.qbs:6 Can't find
variable: project
/qbs/src/lib/qtprofilesetup/qtprofilesetup.qbs:3:1 Errors
[...]

2.2 Building with qmake fails as well:

/usr/local/Qt/5.9.3/gcc_64/bin/qmake -r qbs.pro && make
[...]
g++ -Wl,-z,origin '-Wl,-rpath,$ORIGIN/../lib' -Wl,-O1
-Wl,-rpath,/usr/local/Qt/5.9.3/gcc_64/lib -o ../../../bin/qbs-config-ui
consolelogger.o coloredoutput.o commandlineparser.o main.o mainwindow.o
moc_mainwindow.o   -L/qbs/src/app/config-ui/../../../lib -lqbscore
-L/usr/local/Qt/5.9.3/gcc_64/lib -lQt5Widgets -lQt5Gui -lQt5Core -lGL -lpthread
/usr/bin/ld: cannot find -lGL
collect2: error: ld returned 1 exit status
Makefile:246: recipe for target '../../../bin/qbs-config-ui' failed
make[2]: *** [../../../bin/qbs-config-ui] Error 1

These things are easy to fix, but I assume that nobody has tested the
instructions on this page for a while and nobody is using those Docker
images. I am going to make a patch.

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

[Qbs] tst_blackbox-qt fails

[Richard Weickelt]

Hi,

I tried to build Qbs from source and to run the autotests on Debian stretch
with Qt 5.9.7 and 5.12.0. After creating a Qt profile (with the built Qbs)
and setting the undocumented QBS_AUTOTEST_PROFILE variable I still see some
tests failing in tst_blackbox-qt (see log below).

Looking closer at TestBlackboxQt::includedMocCpp() this test fails even with
Qbs 1.12.2.

I need some guidance how to properly setup the autotests. In addition, I
would like to know how The Qt Company is running Qbs regression tests today
on which platforms and when. The page at
http://doc.qt.io/qbs/building-qbs.html does not talk about autotests and the
docker images are outdated. Thus I assume that the information on this page
is not used.

I would be willing to update the Docker infrastructure and the
documentation. It might be beneficial if anybody could easily run all
autotests without setting anything up on the local system.

Best regards
Richard

* Start testing of TestBlackboxQt *
Config: Using QtTest library 5.12.0, Qt 5.12.0 (x86_64-little_endian-lp64
shared (dynamic) release build; by GCC 5.3.1 20160406 (Red Hat 5.3.1-6))
PASS   : TestBlackboxQt::initTestCase()
PASS   : TestBlackboxQt::addQObjectMacroToGeneratedCppFile()
PASS   : TestBlackboxQt::autoQrc()
PASS   : TestBlackboxQt::cachedQml()
PASS   : TestBlackboxQt::combinedMoc()
PASS   : TestBlackboxQt::createProject()
PASS   : TestBlackboxQt::dbusAdaptors()
PASS   : TestBlackboxQt::dbusInterfaces()
QDEBUG : TestBlackboxQt::includedMocCpp() ERROR: /usr/bin/g++
-Wl,-m,elf_x86_64,-rpath,/usr/local/Qt/5.12.0/gcc_64/lib
-L/usr/local/Qt/5.12.0/gcc_64/lib -m64 -o
/project/default/install-root/tests/auto/blackbox-qt/testWorkDir/included-moc-cpp/default/included-moc-cpp.d2f3350b/included-moc-cpp
/project/default/install-root/tests/auto/blackbox-qt/testWorkDir/included-moc-cpp/default/included-moc-cpp.d2f3350b/3a52ce780950d4d9/main.cpp.o
/project/default/install-root/tests/auto/blackbox-qt/testWorkDir/included-moc-cpp/default/included-moc-cpp.d2f3350b/3a52ce780950d4d9/myobject.cpp.o
/usr/local/Qt/5.12.0/gcc_64/lib/libQt5Core.so.5.12.0 -lpthread

ERROR:
/project/default/install-root/tests/auto/blackbox-qt/testWorkDir/included-moc-cpp/default/included-moc-cpp.d2f3350b/3a52ce780950d4d9/main.cpp.o:
In function `MyObject::MyObject()':
/project/default/install-root/tests/auto/blackbox-qt/testWorkDir/included-moc-cpp/myobject.h:6:
undefined reference to `vtable for MyObject'
/project/default/install-root/tests/auto/blackbox-qt/testWorkDir/included-moc-cpp/default/included-moc-cpp.d2f3350b/3a52ce780950d4d9/main.cpp.o:
In function `MyObject::~MyObject()':
/project/default/install-root/tests/auto/blackbox-qt/testWorkDir/included-moc-cpp/myobject.h:6:
undefined reference to `vtable for MyObject'
collect2: error: ld returned 1 exit status
ERROR: Process failed with exit code 1.
The following products could not be built for configuration default:
included-moc-cpp

QDEBUG : TestBlackboxQt::includedMocCpp() Restoring build graph from disk
Building for configuration default
compiling myobject.cpp [included-moc-cpp]
linking included-moc-cpp [included-moc-cpp]

FAIL!  : TestBlackboxQt::includedMocCpp() Compared values are not the same
   Actual   (runQbs()): 1
   Expected (0)   : 0
   Loc: [/project/tests/auto/blackbox/tst_blackboxqt.cpp(155)]
PASS   : TestBlackboxQt::lrelease()
PASS   : TestBlackboxQt::mixedBuildVariants()
PASS   : TestBlackboxQt::mocAndCppCombining()
PASS   : TestBlackboxQt::mocFlags()
PASS   : TestBlackboxQt::mocSameFileName()
SKIP   : TestBlackboxQt::pkgconfig() pkgconfig or Qt not found
   Loc: [/project/tests/auto/blackbox/tst_blackboxqt.cpp(243)]
PASS   : TestBlackboxQt::pluginMetaData()
QDEBUG : TestBlackboxQt::pluginSupport(request valid plugins) ERROR:
/project/default/install-root/tests/auto/blackbox-qt/testWorkDir/plugin-support/plugin-support.qbs:1:1
Error while handling product 'plugin-support':
/project/default/install-root/tests/auto/blackbox-qt/testWorkDir/plugin-support/modules/m1/m1.qbs:3:5
Dependency 'Qt.plugin_support' not found for product 'plugin-support'.
Please create a Qt profile using the qbs-setup-qt tool if you haven't
already done so.
/project/default/install-root/tests/auto/blackbox-qt/testWorkDir/plugin-support/modules/m2/m2.qbs:2:5
Dependency 'Qt.plugin_support' not found for product 'plugin-support'.
Please create a Qt profile using the qbs-setup-qt tool if you haven't
already done so.

QDEBUG : TestBlackboxQt::pluginSupport(request valid plugins) Build graph
does not yet exist for configuration 'default'. Starting from scratch.
Resolving project for configuration default

FAIL!  : TestBlackboxQt::pluginSupport(request valid plugins) Compared
values are not the same
   Actual   (runQbs(resolveParams) == 0): 0
   Expected (!invalidPlugin): 1
   Loc: [/project/tests/auto/blackbox/tst_blackboxqt.cpp(275)]
FAIL!  : TestBlackboxQt::pluginSupport(request invalid plugin)
'm_qbsStderr.contains("Plugin 'dummy' of type 'i

[Qbs] Future of Qbs

[Richard Weickelt]

Dear all,

on the Qt developer mailing list, Lars Knoll recently announced:

> We have been developing Qbs over the last years, and as such are
> committed to it for some more time. We are planning on another feature
> release in the first quarter of next year and will support it in Qt

> Creator for at least another year. Qbs is open source and if someone
> wants to take over and develop it further let us know as well. I’d also
> like to use this place to thank Christian and Jörg for all their great
> work on Qbs  (and of course also anybody else who contributed to it).

Qbs is open source but the largest part of development has always been
shouldered by The Qt Company and the decision processes have never been open
and transparent.

It would be great if the TQtC could clarify what is planned for the next
feature release and why. I would be glad if the TQtC would spend the
remaining resources on transitioning the Qbs project into a community
ownership. I have no experience how a successful transition could look like.
Therefore I am asking for role models.

What I can think of, but I might be wrong: TQtC maintainers, please
communicate upfront what you are going to do, how and why so that others can
learn. Some questions, I think, we should clarify on the mailing list:

- Can we define milestones for a successful transition and clarify what
  TQtC is willing to invest?
- There were some companies using Qbs for their own projects [1]. Can we get
  committment from those?
- Can we keep using TQtC infrastructure, domain wtc.?
- How does the release process of Qbs work?
- Are there parts in the codebase that make maintenance difficult and
  that could be simplified? Maybe parts duplicating Qt code that should
  be rebased onto Vanilla Qt?

Thank You
Richard Weickelt


[1]
https://docs.google.com/spreadsheets/d/1CwXx2F1zuATYY3GGOTkFgDB9jwMPghf6az_RVOnskfk/edit#gid=0
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Qbs vs Jenkins

[Richard Weickelt]

> I am wondering if it was possible to replace the Jenkins pipeline with only 
> Qbs. In theory I see no reason why this should not work given the flexibility 
> of the Qbs but is there any specific functionality out of the box that could 
> make the typicial tasks performed by Jenkins easier? Specifically:
>  
> * Download sources from Bitbucket (Git)
> * Running the build using MSBuild .proj file
> * Publishing the build artifacts to external server
>  
> All of it can obviously be performed by using Javascript/Commands/Custom 
> rules in Qbs but maybe some of it is already there so I would not need to 
> reinvent the wheel. Also there is a question of bootstrapping such a build 
> system since Jenkins server does have web-based front-end. But I guess it can 
> even be used through it with Jenkins simply running the Qbs. Or perhaps it is 
> a silly idea since Qbs was not meant to be used this way?

I am interested in this topic as well.

* What do you mean by "question of bootstrapping such a build system since
  Jenkins server does have web-based front-end"?
* Do you want to replace Jenkins completely with Qbs?
* In bigger projects you will most likely have dependencies on other
  projects. You don't want to reinvent package management, do you.
  Conan + Artifactory is used a lot for that purpose. Conan and Qbs are
  good friends. [1]

In general, I think that a declarative DSL somehow similar to the Qbs' QML
dialect would be very nice for describing continuous delivery pipelines.
Especially the Depends and Export item pair would provide a side-effect free
way to forward data from one job to another and would allow proper
parallelization of jobs. There could be more QML items, for instance, to
span a parameter matrix on multiple jobs. Many CI services use yaml these
days, but my personal impression is that yaml is much harder to read, to
write and to rehearse than QML.

Richard

[1] https://docs.conan.io/en/latest/reference/generators/qbs.html#qbs-generator
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs