Re: [Qbs] Application with QML_ELEMENT in library, problem with plugins.qmltypes
On 5/14/24 10:11 AM, Stéphane Fabry wrote:
-> i took the "plugins.qmltypes" located in
"Release_Desktop__6bebb707edc597ff\carlib.83bede55" and copy paste manually in the app build dir
("Release_Desktop__6bebb707edc597ff\app.7d104347") and there it is working.
But i have no clue on how to ask the library to build/install/deploy its own
qmltypes in the build directory of the application :/
You need to arrange this yourself by defining suitable *install*
locations that are shared among the products involved, e.g. via a
project-level property.
So if the application and the qmltypes file have to be at the same
location (surely that's not the canonical way? but I'm not a QML
expert), then they need to get the same qbs.installDir value. Installing
the .qmltypes file is achieved by setting Qt.qml.typesInstallDir (see
https://doc.qt.io/qbs/qml-qbsmodules-qt-qml.html#typesInstallDir-prop).
Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Application with QML_ELEMENT in library, problem with plugins.qmltypes
On 5/14/24 9:17 AM, Stéphane Fabry via Qbs wrote: The projet is running fine, the problem lies in the QtCreator loading the qmltypes. It loads correctly the "app.qmltypes" located next to the app.exe but it won't load the library "plugins.qmltypes" located next to the dll. Did I miss something ? You mean you want Qt Creator to pick up the import that is being generated when building that very same project to which Main.qml belongs? Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] qbs 2.3.1 released
Hi, we have released qbs 2.3.1 today. As usual, sources, binaries, change log etc can be found here: https://download.qt.io/official_releases/qbs/2.3.1/ This release of qbs is also part of Qt Creator 13.0.1. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] qbs 2.3 released
On 4/9/24 10:37 AM, Leon Buckel wrote: Where can we find the changlog? It doesn’t seem to be in the usual location. We forgot to create one; sorry about that. It would have looked something like this: - Added an LSP language server that provides support for following symbols and completion in IDEs. - Module properties are now directly available within groups in modules (QBS-1770). - Added new module Exporter.cmake. - Deprecated the pkgconfig-based fallback module provider. - Adapted darwin support to Xcode 15.3. - If a project needs to be re-resolved, we now print the reason. - Added some tutorials. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] how to run in parallel?
On 4/9/24 9:15 AM, Heiko Nardmann wrote: I use "qbs run" within a python script to execute testframes. Yesterday I've changed the script and tried to run multiple "qbs run" in parallel. This has failed as Qbs locks the build graph. So ... how do I execute multiple testframes in parallel using Qbs eco system? That's currently not supported, though at first glance I don't see why the run command could not be extended to support multiple products. You might want to file a feature request. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] qbs 2.3 released
Hi, we have released qbs 2.3.0 today. As usual, sources, binaries, change log etc can be found here: https://download.qt.io/official_releases/qbs/2.3.0/ This release of qbs is also part of Qt Creator 13.0.0. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Branch 2.3 created
Hi, we have branched off Qbs 2.3. Scheduled release date for version 2.3.0 is end of March (together with Qt Creator 13.0). We recommend users to try this branch with their projects and report back any new problems they find. 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. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] qbs 2.2.2 released
Hi, we have released qbs 2.2.2 today. As usual, sources, binaries, change log etc can be found here: https://download.qt.io/official_releases/qbs/2.2.2/ This release of qbs is also part of Qt Creator 12.0.2. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Code Generator with shared library dependencies
On 1/12/24 11:10, Leon Buckel wrote: 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? There isn't, but there should be. In the past I’ve solved this problem by deploying the tool and dlls first and running it from the install root. That still works but doesn’t seem right. Especially since I don’t believe there is a way to tell whether the artifacts are already installed before running the Command. If the tool is installable, then it's safe to assume is already has been installed when running it, as installation happens in lockstep with artifact creation. The user would have to actively sabotage you by disabling installation. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Building a universal binary with multiplexing
On 1/9/24 09:05, Leon Buckel wrote: The issue I’m having now is that for the aggregate step I don’t want to run the build command again. So I would have to somehow check if the current run is the aggregate and just return an empty command array. The question now is: How do I check that? You can identify the aggregate by this condition: product.aggregate && !product.multiplexConfigurationId The latter property is undocumented. Perhaps we should introduce product.isAggregate. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Accessing overloaded properties
On 1/8/24 12:37, Jochen Becher via Qbs wrote:
I havbe a question about qbs syntax. My qbs files look like this:
MyProject.qbs:
Project {
property string installDir: { throw "installDir must be set" }
}
AProject.qbs:
MyProject {
id: solution
installDir: "myfolder"
MyProject {
installDir: solution.installDir + "/mysubfolder"
}
}
My question is about"solution.installDir". Using "project.installDir"
doesn't work. "outer.installDir" or "base.installDir" is also not
allowed or not what I want.
What about "parent.installDir"?
But I am not sure if defining "id" and using it in a subitem like in
QML is really supported. It works and is sometimes but it is not
documented in the qbs manual.
In hindsight, it was a mistake to support QML ids in qbs, because there
are too many contexts in which they do not make sense due to the
syntactic context not matching the semantic one (modules!).
My advice as to when to use them:
- In Probes, because that's how the mechanism officially works.
- In Depends items, if the dependee has an "unfortunate" name (e.g.
with spaces) and you want to set properties on it.
- Nowhere else.
In practice, Project items are probably safe, because there is no
multiplexing of any kind involved.
Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] qbs 2.2 released
Hi, we have released qbs 2.2.1 today. As usual, sources, binaries, change log etc can be found here: https://download.qt.io/official_releases/qbs/2.2.1/ This release of qbs is also part of Qt Creator 12.0.1. Please also take a look at https://lists.qt-project.org/pipermail/qbs/2023-September/003097.html, if you haven't done so already. In case you are wondering what happened to 2.2.0: We had two serious problems that made us essentially skip that release: 1) Our CI job for producing release binaries was broken and we did not manage to fix it in time. 2) qbs stopped working at all with the latest MSVC (https://bugreports.qt.io/browse/QBS-1743). Technically, it does exist, though, in that it is tagged accordingly and shipped as part of Qt Creator 12.0.0. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Branch 2.2 created
Hi, we have branched off Qbs 2.2. Scheduled release date for version 2.2.0 is end of November (together with Qt Creator 12.0). We recommend users to try this branch with their projects and report back any new problems they find; see also https://lists.qt-project.org/pipermail/qbs/2023-September/003097.html. 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. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] qbs 2.1.2 released
Hi, we have released qbs 2.1.2 today. As usual, sources, binaries, change log etc can be found here: https://download.qt.io/official_releases/qbs/2.1.2/ This release of qbs is also part of Qt Creator 11.0.3. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] How to use 'qbs' in a JavaScript function?
On 9/5/23 12:08, Jochen Becher wrote:
until qbs 1.9 the following works:
Not on purpose, though.
Quite a number of things "worked" that shouldn't have, as there was a
lot of scope pollution.
import qbs 1.0
import import 'utils.js' as Utils
Probe {
id: workspaceRootDetector
property path rootDir
configure: {
rootDir = Utils.detectWorkspaceRoot(qbs)
}
}
Since qbs 2.0.2 (from QtCreator 10.0.2), I get the following error
message from calling Utils.detectWorkspaceRoot:
'qbs' is not defined
'qbs' is used within Utils.detectWorkspaceRoot to access some
properties from qbs, e.g.,
return qbs.targetOS.contains("windows") ? "D:/projects" : "/projects"
How can I achieve the same with qbs 2.0.2?
Store the data you are interested in as input properties:
Probe {
id: workspaceRootDetector
// Inputs:
property stringList targetOS: qbs.targetOS
// ...
// Outputs:
property path rootDir
configure: {
rootDir = Utils.detectWorkspaceRoot(targetOS/*, ...*/)
}
}
Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] Heads up: Multi-threaded project resolving
Hi, we have just merged a patch into the master branch (https://codereview.qt-project.org/c/qbs/qbs/+/493783) that employs parallelization to resolve projects. It should result in a noticeable speed-up for projects with lots of products. We advise you to check that your personal projects still work fine after this. If you notice any regressions, please file an issue at bugreports.qt.io. Thanks, Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] qbs 2.1.1 released
Hi, we have released qbs 2.1.1 today. As usual, sources, binaries, change log etc can be found here: https://download.qt.io/official_releases/qbs/2.1.1/ This release of qbs is also part of Qt Creator 11.0.1. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] qbs 2.1 released
Hi, we have released qbs 2.1.0 today. As usual, sources, binaries, change log etc can be found here: https://download.qt.io/official_releases/qbs/2.1.0/ This release of qbs is also part of Qt Creator 11.0.0. Please also take a look at https://lists.qt-project.org/pipermail/qbs/2023-April/003083.html, if you haven't done so already. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Qbs 2.0.2 released
Hi, we have released qbs 2.0.2 today. As usual, sources, binaries, change log etc can be found here: https://download.qt.io/official_releases/qbs/2.0.2/ This release of qbs is also part of Qt Creator 10.0.2. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] passing values for stringList properties on commandline?
On 6/9/23 10:15, Heiko Nardmann wrote: Hi together, I'm currently analyzing the usage of ccache and would like to pass "-v" to ccache. Which means that I have to change modules.cpp.compilerWrapper:ccache to sth like modules.cpp.compilerWrapper:'[ccache,-v]' which does not work. Because it's not a string list, i.e. an array of JS strings: modules.cpp.compilerWrapper:'["ccache","-v"]' Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Branch 2.1 created
Hi, we branched off Qbs 2.1. Scheduled release date for version 2.1.0 is end of July (together with Qt Creator 11.0). We recommend users to try this branch with their projects and report back any new problems they find; see https://lists.qt-project.org/pipermail/qbs/2023-April/003083.html as to why this is particularly relevant this time. 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. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] url access resp. download functionality?
On 5/25/23 14:45, Heiko Nardmann wrote: I wonder whether my research missed some builtin functionality inside Qbs resp. contained JS that provides a way to download files resp. access URLs? No, you'll have to invoke externel tools for that. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Qbs 2.0.1 released
Hi, we have released qbs 2.0.1 today. As usual, sources, binaries, change log etc can be found here: https://download.qt.io/official_releases/qbs/2.0.1/ This release of qbs is also part of Qt Creator 10.0.1. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Heads up: New project resolving implementation
Hi, we have just merged https://codereview.qt-project.org/c/qbs/qbs/+/459764 into the master branch, which improves speed and correctness when loading projects. You should give it a try if you have projects that take excessively long to resolve; chances are that you will see improvements. We also generally recommend to check your projects with it, as it might uncover subtle mistakes in your project files that went unnoticed so far due to implementation bugs. And of course there is as always the possibility that the new code has new bugs, in which case we'd appreciate a report at bugreports.qt.io. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] qbs 2.0 released
Hi, we have released qbs 2.0.0 today. As usual, sources, binaries, change log etc can be found here: https://download.qt.io/official_releases/qbs/2.0.0/ This release of qbs is also part of Qt Creator 10.0.0. Please also take a look at https://lists.qt-project.org/pipermail/qbs/2023-February/003067.html, if you haven't done so already. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] dynamically add properties?
On 3/2/23 13:30, Heiko Nardmann wrote: how do I use "Object.defineProperty" to add a new property to the 'product' of a Rule? I've tried several things but most times I just get some "undefined" for the property set. The product variable represents a Product item with its properties. You must not mess with it in JS code. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] SHA256 ?
On 3/1/23 17:31, Heiko Nardmann wrote: is there already some functionality inside the Qbs services or Javascript to perform a SHA256 for a file? Maybe I've missed sth. ... ? If you want *some* kind of hash (for uniquely mapping file paths), there's Utilities.getHash(). More specific stuff would be overkill; qbs is not a JS library. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Qbs 1.24.1 released
Hi, we have released qbs 1.24.1 today. As usual, sources, binaries, change log etc can be found here: https://download.qt.io/official_releases/qbs/1.24.1/ This release of qbs is also part of Qt Creator 9.0.2. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] ModuleProvider concept
On 2/16/23 09:53, Heiko Nardmann wrote: I'm trying to understand the ModuleProvider concept. Is this something I should look for when trying to retrieve parts - "Depends" - of my project from e.g. Artifactory? If your modules cannot be "static", i.e. you need to query some external resource to *create* the files (rather than just fill in property values), then that would fit the use case. For a real-world example, you might want to look at the Qt module provider that's shipped with qbs. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] HEADS UP: Branch 2.0 created/Testing strongly recommended
Hi, we have branched off qbs 2.0 today. As indicated by the version jump, this is a major update in that we switched the JavaScript engine from QtScript to QuickJS. While there are no intentional changes (except removing some functions deprecated years ago), it is possible that the new engine will uncover dormant bugs in project files (e.g. QtScript was rather generous in accepting undefined values where it didn't have to). Of course, user projects could also expose bugs on our side that were not caught by our tests. It is therefore an even better idea than usual to check this release branch against your projects. The planned release date is end of March. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Qbs 1.23.2 released
On 10/26/22 13:38, Christian Kandeler via Qbs wrote: On 10/26/22 13:24, Иван Комиссаров wrote: I think, both RPATH and RUNPATH should work. My understanding is that RUNPATH only affects libraries with a NEEDED entry, i.e. direct dependencies, while RPATH covers indirect dependencies as well. What I don't understand is why Pavel's linker uses RUNPATH and mine uses RPATH by default. Could it be that distributions patch binutils according to their preferences? Hm, and now after updating ArchLinux, I also have RUNPATH in my binaries. So I suppose we do need such a patch? Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Get rid of extra product type statements when generating graphviz dependency graphs using qbs
On 12/12/22 11:34, q...@mein-briefkasten.net wrote: As it turns out product.dependencies is just what I was looking for in the first place. This is of great help. Is there any documentation about what properties I can expect in product (and are stable to stay there over version changes)? Seems this variable is not explicitly documented, but you can rely on the dependencies property. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Get rid of extra product type statements when generating graphviz dependency graphs using qbs
On 12/11/22 19:08, q...@mein-briefkasten.net wrote:
Just "Depends { name: "depgraph” }” was not enough, I had to extend the type of
every lib to get all dependencies show up in the graph, i.e.
Yes, and the reason is explained here:
https://doc.qt.io/qbs/qml-qbslanguageitems-rule.html#rules-and-product-types
Depends { name: "depgraph" }
type: base.concat(["dot-fragment”])
You want
https://doc.qt.io/qbs/qml-qbslanguageitems-module.html#additionalProductTypes-prop.
The leanest way from a qbs user perspective would be to just do a
-
CppApplication {
name: “app”
...
}
DotDependencyGraph {
name: “app-dependency-graph”
Depends { name: “app” }
}
-
So no need to add a Depends to every related product and just pull the
dependencies via the single app dependency, but no idea if this would be
possible and how to do it.
It's just a matter of how you write your rule, no? You have access to
the dependency tree of products via product.dependencies.
Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] Qbs 1.24 released
Hi, we have released qbs 1.24.0 today. As usual, sources, binaries, change log etc can be found here: https://download.qt.io/official_releases/qbs/1.24.0/ This release of qbs is also part of Qt Creator 9.0.0. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Qbs 1.23.2 released
On 10/26/22 13:24, Иван Комиссаров wrote: I think, both RPATH and RUNPATH should work. My understanding is that RUNPATH only affects libraries with a NEEDED entry, i.e. direct dependencies, while RPATH covers indirect dependencies as well. What I don't understand is why Pavel's linker uses RUNPATH and mine uses RPATH by default. Could it be that distributions patch binutils according to their preferences? Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Qbs 1.23.2 released
On 10/24/22 16:15, Карелин Павел wrote: 24.10.2022 16:58, Christian Kandeler via Qbs пишет: On 10/24/22 15:38, Карелин Павел wrote: 24.10.2022 13:48, Christian Kandeler via Qbs пишет: On 10/24/22 12:34, Карелин Павел wrote: I think runpath is wrong for libqbscore.so.1.23.2: instead of '$ORIGIN/../lib/qtcreator' it should be '$ORIGIN/../../lib/qtcreator' Why? bin/ and lib/ are located on the same level. Because loading the libqbsscriptengine.so.1.23 library comes from libqbscore.so.1.23.2, not bin/qbs. I conducted an experiment: in the libqbscore.so.1.23.2 I replaced runpath from '$ORIGIN/..:$ORIGIN/../lib/qtcreator:/opt/qt515/lib' to '$ORIGIN/../../lib/qtcreator:/opt/qt515/lib:/usr/bi' And everything worked for me. The problem seems to be differences in linker behavior. My binaries have RPATH set, yours use RUNPATH. The former works recursively, the latter doesn't. What linker are you using? I have binutils 2.39. Systerm compiler from Ubuntu 20.04. GCC version 9.4.0 That doesn't answer the linker question. In my qbs projects, I explicitly use RPATH instead of RUNPATH using the following command: cpp.driverLinkerFlags: [ "-Wl,--disable-new-dtags", ] My man page says: By default, the new dynamic tags are not created. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Qbs 1.23.2 released
On 10/24/22 15:38, Карелин Павел wrote: 24.10.2022 13:48, Christian Kandeler via Qbs пишет: On 10/24/22 12:34, Карелин Павел wrote: I think runpath is wrong for libqbscore.so.1.23.2: instead of '$ORIGIN/../lib/qtcreator' it should be '$ORIGIN/../../lib/qtcreator' Why? bin/ and lib/ are located on the same level. Because loading the libqbsscriptengine.so.1.23 library comes from libqbscore.so.1.23.2, not bin/qbs. I conducted an experiment: in the libqbscore.so.1.23.2 I replaced runpath from '$ORIGIN/..:$ORIGIN/../lib/qtcreator:/opt/qt515/lib' to '$ORIGIN/../../lib/qtcreator:/opt/qt515/lib:/usr/bi' And everything worked for me. The problem seems to be differences in linker behavior. My binaries have RPATH set, yours use RUNPATH. The former works recursively, the latter doesn't. What linker are you using? I have binutils 2.39. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Qbs 1.23.2 released
On 10/24/22 12:34, Карелин Павел wrote: I think runpath is wrong for libqbscore.so.1.23.2: instead of '$ORIGIN/../lib/qtcreator' it should be '$ORIGIN/../../lib/qtcreator' Why? bin/ and lib/ are located on the same level. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Qbs 1.23.2 released
On 10/21/22 16:58, Карелин Павел wrote: I have a question: does anyone use QtC builded using QBS? The fact is that in QtC 8, the QBS build system does not work. See picture in the attachment. The inscription in the red rectangle is "Failed to retrieve version." The problem is in improperly spelled out path to QBS libraries. "Spelled out" where? We use rpaths by default, and they work fine here. What do yours look like? Also the install location should not matter, as they are relative to the executable. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Qbs 1.23.2 released
Hi, we have released qbs 1.23.2 today. As usual, sources, binaries, change log etc can be found here: https://download.qt.io/official_releases/qbs/1.23.2/ This release of qbs is also part of Qt Creator 8.0.2. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Branch 1.24 created
Hi, we branched off Qbs 1.24. Scheduled release date for version 1.24.0 is end of November (together with Qt Creator 9.0). We recommend users to try this branch with their projects and report back any new problems they find. 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. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Running the target through a wrapper
On 10/8/22 18:17, Alberto Mardegan wrote: Hi all! On some occasions I've found myself in need of debugging the executable under gdb, strace and valgrind. Running gdb ./default/install-root/usr/local/bin/MyApp has always worked well for me, but I wonder: 1) Would this break if the app depends on shared libraries existing in the same project, unless the user explicitly sets LD_LIBRARY_PATH to the proper locations? Yes. 2) Can we make it even simpler? I'm considering the idea of adding an option to run the target under a wrapper, something like qbs run --products MyApp --wrapper "valgrind --trace-children=yes" Does anyone have plans to implement something similar? If not, and if you think that the idea is sound, I might give it a go (hints welcome). RunEnvironment::doRunTarget() has some hardcoded wrapper logic for Android and iOS; you could try generalizing it. Some Desktop/remote differentiation will likely be necessary, i.e. set LD_LIBRARY_PATH & friends only for the former. (We could be more ambitious and set things up on the remote side too, e.g. when the wrapper is ssh. But that's probably out of scope for the first iteration). Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Language Proposal: A generic `Item{}` for classifying bindable objects. Christian Kandeler
On 9/6/22 12:20, hug-animals via Qbs wrote: Encapsulation: "Access into nested items isnt explicitly supported in QML" Hard to know what you mean exactly, because you can set properties of nested items. Could you give an example of what is explicitly prohibited? If you've worked on even just a single QML project, you have more experience than me, so I probably just mis-remembered. I though it was not possible. - Why would the item pool use `std::vector m_items;` instead of a QList ( Or QVector ) ? I imagine it was a performance consideration, but it always puzzles me to see stdlib in most qt code. https://codereview.qt-project.org/c/qbs/qbs/+/261870 - There are three Values -- Item, JSSource, and Variant. I have only been able to create JSSource when making a qbs file. What are the other two used for? VariantValues come not from source code, but from the command line or profiles. ItemValues are the non-leaf parts of a nested property binding: property string version: Qt.core.version // "Qt" and "core" are item values Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Language Proposal: A generic `Item{}` for classifying bindable objects.
On 9/2/22 04:13, hug-animals via Qbs wrote:
Product {
/* Syntax 1 */
property var feed: Item {
property string hobo
property var seed: Item {
property string chuck
}
}
Probably the most sensible of the variants.
Perhaps also:
property MyItem prop
where MyItem is defined as an Item subtype somewhere.
Somewhat related QML feature: inline components
(https://www.qt.io/blog/new-qml-language-features-in-qt-5.15).
/* In use */
import "Sneed.qbs" as Sneed
Sneed {
feed.hobo : "Hobo"
feed.seed.chuck: "Chuck"
Access into nested items is afaik explicitly not supported in QML as it
breaks encapsulation, but if I understand correctly, your Items are
basically just type-safe JS objects.
Is this important?Yes, insofar as it reduces namespace pollution in a practical
way that is currently impossible.
Playing devil's advocate: Why has no one needed this in QML so far?
Potential Drawbacks:- This does depart a bit from QML syntax rules.
You'd definitely need to adapt the parser (which is currently reused
as-is from QML), as well as the evaluation machinery. Difficult to say
how much work that would be.
Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] Qbs 1.23.1 released
Hi, we have released qbs 1.23.1 today. As usual, sources, binaries, change log etc can be found here: https://download.qt.io/official_releases/qbs/1.23.1/ This release of qbs is also part of Qt Creator 8.0.1. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Qbs 1.23 released
We have released qbs 1.23.0 today. As usual, sources, binaries, change log etc can be found here: https://download.qt.io/official_releases/qbs/1.23.0/ This release of qbs is also part of Qt Creator 8.0.0. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Branch 1.23 created
Hi, we branched off Qbs 1.23 today. Scheduled release date for version 1.23.0 is mid-July (together with Qt Creator 8.0). We recommend users to try this branch with their projects and report back any new problems they find. 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. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Strange error with QBS 1.22.1 on Android
On 5/24/22 22:53, Alberto Mardegan wrote: It came from this: cpp.defines: product.embedAsResource ? "STATIC_PLUGINS" : "" Changing the "" to a [] fixes the issue. Do you think that this handling of "" could be considered a QBS bug? More like a quality-of-implementation issue. In general, we don't want too much "smartness" and second-guessing user choices, but in this particular case we know that -D by itself is not valid and can prevent that (with a diagnostic). Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Selecting target architecture for Android
On 5/23/22 22:32, Alberto Mardegan wrote: I do have an "install: true" on the library product, indeed. But I thought this was needed to have the library installed on Linux? It is. If you want to be precise, you can make the value of this property dependent on the target, e.g. use a Properties item with the condition true for non-Android. This way, at the very least you won't have extra binaries in your install dir. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Retrieving project options
On 5/22/22 22:00, Alberto Mardegan wrote: how do I find out, from within a QBS build directory, what where the command-line options which I passed to QBS to initialize the project? There is no command-line option to extract this information directly. However, it will be printed if you build again (without a resolve command) with different command-line options. So you can just do this: $ qbs modules.qbs.toolchainType:dummy And similarly with the profile name. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Selecting target architecture for Android
On 5/22/22 21:57, Alberto Mardegan wrote:
So far I've built my Android application using Qt 5.12, for the arm
architecture only, and everything has worked fine.
Today I tried migrating to 5.15, which supports multiarch, and I'm
getting an issue: after building all the files for all the four
supported architectures ("Qt with multiple abi detected:
'armeabi-v7a,arm64-v8a,x86,x86_64'"), I get an error during the
install phase:
==
ERROR: Cannot install files
'/home/mardy/src/git/mappero/abuild/default/MapperoCore.eyJhcmNoaXRlY3R1cmUiOiJ4ODZfNjQifQ--.8341646d/libMapperoCore.so'
and
'/home/mardy/src/git/mappero/abuild/default/MapperoCore.eyJhcmNoaXRlY3R1cmUiOiJhcm02NCJ9.14539b45/libMapperoCore.so'
to the same location
'/home/mardy/src/git/mappero/abuild/default/install-root/usr/local/lib/libMapperoCore.so'.
If you are attempting to install a directory hierarchy, consider using
the qbs.installSourceBase property.
==
Presumably you have set qbs.install to true somewhere in the library
product, with no per-arch differentiation, leading to a conflict. Since
in the Android case the libraries are not the final build artifact, they
should not get installed.
where MapperoCore is a DynamicLibrary. But actually I didn't spend
time investigating this (and neither should you), because I don't
really care about other architectures: I would be happier if my
Android package contained just the armv7 binaries :-)
But how do I do that? I tried specifying
"qbs.architectures:armeabi-v7a" to QBS's command line, but then it
looks like it cannot find the Qt libraries:
NDK ABI name and qbs architecture name are not always the same. I
suppose qbs.architecture would be armv7a here.
Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Failed 'PackageBuild' product on QBS 1.22
On 5/17/22 17:40, Карелин Павел wrote: In passing, one more question: the libmod.qbs file does not appear in the project tree in QtC. It does, in the last tree branch, "Qbs files". Note that in your attached project, qbssearchPaths is missing, so if that worked on your system, then the library might have been pulled in from somewhere else, such as a global search path. The qbsSearchPaths parameter is present. See file project.qbs Right, I saw only product.qbs. In my work projects, the "Qbs files" section is present. And in this mini-project, for some reason, it is not. So I decided to pay attention to this. It is for me. Have you perhaps checked "simplify tree" in the project tree settings? Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Failed 'PackageBuild' product on QBS 1.22
On 5/15/22 19:27, Карелин Павел wrote: A new question has appeared: the list of libraries in the product can be changed. See "lib.libmod.dynamicLibraries" in the product.qbs, line 13. The adjusted list will not be included in the rule. It can be fixed? That's because you access the dynamicLibraries property via the module id, which is a file-scope thing. Don't ever use ids, except for Probes. Instead, access the property via the product variable: product.lib.modlib.dynamicLibraries. In passing, one more question: the libmod.qbs file does not appear in the project tree in QtC. It does, in the last tree branch, "Qbs files". Note that in your attached project, qbssearchPaths is missing, so if that worked on your system, then the library might have been pulled in from somewhere else, such as a global search path. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Failed 'PackageBuild' product on QBS 1.22
On 5/12/22 21:10, Карелин Павел wrote: John, thanks for the tip. Unfortunately, this was not enough, the rule is still not called. Looks like something else is needed... Christian, can I ask you for help on this issue? Try to distill the project into a minimal, self-contained example. Ideally, you'll find the problem while doing that. If not, please post the result here. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Depending on binary from install-root
On 5/7/22 10:33, Jochen Becher wrote: Am Mittwoch, dem 22.09.2021 um 10:45 +0200 schrieb Christian Kandeler: On 9/9/21 1:25 PM, Jochen Becher wrote: thank you for the prompt answer. Adding explicit dependency on "installable" works. But adding the input dependency on application does not: The rule uses inputs: [ "alang"] to depend on the alang source code files. When I add additionally inputsFromDependencies: [ "application" ] it doesn't work. inputs["application"] is always undefined. There's almost surely something wrong in one of your rules/products then. You will probably find out what it is if you try to create a minimal example. Seems like inputs and inputsFromDependencies are mutual exclusive. Definitely not, as that's exactly what e.g. the rule creating applications has, where the inputs are object files and the inputs from dependencies are (import) libraries. Long time ago, but I ran again into this issue and now found out my problem with it: Of course, you are right, the properties inputs and inputsFromDependencies are not mutual exclusive. But: I used variable "input" at one place in my prepare code. With that, the inputs variable contains only the tags from "inputs" and not from "inputsFromDependencies". If I only access "inputs" in prepare code, it contains all tags. Very unexpected behaviour (and I believe undocumented as well). "input" is a convenience variable that should exist if and only if there is exactly one input artifact, in which case it saves you from writing inputs[tag][0]. The set of input artifacts considered for this decision should include all inputs, including inputsFromDependencies. If that's not the case, please file a bug report. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Failed 'PackageBuild' product on QBS 1.22
On 5/10/22 15:02, Карелин Павел wrote:
05.05.2022 12:14, Christian Kandeler пишет:
On 5/5/22 11:00, Карелин Павел wrote:
05.05.2022 10:47, Christian Kandeler пишет:
On 5/4/22 18:18, Карелин Павел wrote:
Christian, how would you solve my problem?
After the project is built, the deb-package is assembled. To build
the deb-package, you need a list of dependent libraries (not all,
only parts, system dependencies no required). For example this list:
/opt/ffmpeg/4.4/lib/libavutil.so*
/opt/ffmpeg/4.4/lib/libswscale.so*
/opt/ffmpeg/4.4/lib/libswresample.so*
/opt/opencv/4.5.5/lib/libopencv_core.so*
/opt/opencv/4.5.5/lib/libopencv_calib3d.so*
/opt/opencv/4.5.5/lib/libopencv_imgproc.so*
I can get library paths and names of so-modules from dependencies:
Depends { name: "lib.ffmpeg" }
Depends { name: "lib.opencv" }
How can I create such a list and put it in the package_build_info
file? With the rules?
lib.ffmpeg and lib.opencv are modules in your projects?
Yes, they are modules. I use my own QBS-extensions to include
third-party assembled libraries in my projects
(https://github.com/hkarel/QbsExt/tree/master/modules/lib).
Then I think the correct way is to
- collect these libraries in a Group in the respective module
- mark them as target artifacts (see
https://doc.qt.io/qbs/qml-qbslanguageitems-group.html#filesAreTargets-prop)
- give them a suitable tag
- on the consuming side, create a rule whose
inputsFromDependencies matches that tag and in this rule, do whatever
you need to do.
Tried to follow you recommendation:
--- LibModule ---
Module {
id: libmod
property string prefix
property string version: ""
property bool enabled: true
property bool useSystem: false
property string includeSuffix: "/include"
property string libSuffix: "/lib"
property path includePath: (useSystem || !enabled)
? undefined
: prefix + (version.length ? "/" +
version : "") + includeSuffix
property path libraryPath: (useSystem || !enabled)
? undefined
: prefix + (version.length ? "/" +
version : "") + libSuffix
property var dynamicLibraries: ["sodium"]
property var staticLibraries: []
...
Group {
//name: "package-build"
fileTags: "package-build"
filesAreTargets: true
files: {
var libfiles = [];
if (!libmod.useSystem && libmod.enabled)
for (var i in libmod.dynamicLibraries) {
libfiles.push(
libmod.libraryPath +
("/lib{0}.so*").format(libmod.dynamicLibraries[i]))
}
console.info("=== libfiles ===");
console.info(libfiles);
return libfiles;
}
}
} // Module
LibModule {
id: sodium
version: "1.0.x"
prefix: "/opt/sodium"
checkingHeaders: ["sodium.h"]
dynamicLibraries: ["sodium"]
staticLibraries: ["sodium"]
}
Product {
name: "ToxPhone"
...
Depends { name: "lib.sodium" }
...
lib.sodium.version: project.sodiumVersion
//lib.sodium.useSystem: project.useSystemSodium
Rule {
id: pkgbuild
//inputs: ["package-build"]
inputsFromDependencies: ["package-build"]
Artifact {
fileTags: ["package-build-file"]
filePath: FileInfo.joinPaths(project.buildDirectory,
"package_build_info")
}
prepare: {
var outputFile =
FileInfo.joinPaths(project.buildDirectory, "package_build_info");
console.info("=== outputFile ===");
console.info(outputFile);
}
}
} // Product
The inscription "=== outputFile ===" is never printed. What am I doing
wrong?
Did you remember to connect the "package-build-file" tag to your product
type? Either by making this tag the product type or via a chain of rules.
Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Failed 'PackageBuild' product on QBS 1.22
On 5/5/22 11:00, Карелин Павел wrote:
05.05.2022 10:47, Christian Kandeler пишет:
On 5/4/22 18:18, Карелин Павел wrote:
Christian, how would you solve my problem?
After the project is built, the deb-package is assembled. To build
the deb-package, you need a list of dependent libraries (not all,
only parts, system dependencies no required). For example this list:
/opt/ffmpeg/4.4/lib/libavutil.so*
/opt/ffmpeg/4.4/lib/libswscale.so*
/opt/ffmpeg/4.4/lib/libswresample.so*
/opt/opencv/4.5.5/lib/libopencv_core.so*
/opt/opencv/4.5.5/lib/libopencv_calib3d.so*
/opt/opencv/4.5.5/lib/libopencv_imgproc.so*
I can get library paths and names of so-modules from dependencies:
Depends { name: "lib.ffmpeg" }
Depends { name: "lib.opencv" }
How can I create such a list and put it in the package_build_info
file? With the rules?
lib.ffmpeg and lib.opencv are modules in your projects?
Yes, they are modules. I use my own QBS-extensions to include
third-party assembled libraries in my projects
(https://github.com/hkarel/QbsExt/tree/master/modules/lib).
Then I think the correct way is to
- collect these libraries in a Group in the respective module
- mark them as target artifacts (see
https://doc.qt.io/qbs/qml-qbslanguageitems-group.html#filesAreTargets-prop)
- give them a suitable tag
- on the consuming side, create a rule whose inputsFromDependencies
matches that tag and in this rule, do whatever you need to do.
Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Failed 'PackageBuild' product on QBS 1.22
On 5/4/22 18:18, Карелин Павел wrote:
Christian, how would you solve my problem?
After the project is built, the deb-package is assembled. To build the
deb-package, you need a list of dependent libraries (not all, only
parts, system dependencies no required). For example this list:
/opt/ffmpeg/4.4/lib/libavutil.so*
/opt/ffmpeg/4.4/lib/libswscale.so*
/opt/ffmpeg/4.4/lib/libswresample.so*
/opt/opencv/4.5.5/lib/libopencv_core.so*
/opt/opencv/4.5.5/lib/libopencv_calib3d.so*
/opt/opencv/4.5.5/lib/libopencv_imgproc.so*
I can get library paths and names of so-modules from dependencies:
Depends { name: "lib.ffmpeg" }
Depends { name: "lib.opencv" }
How can I create such a list and put it in the package_build_info
file? With the rules?
lib.ffmpeg and lib.opencv are modules in your projects?
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Failed 'PackageBuild' product on QBS 1.22
On 5/3/22 21:44, Карелин Павел wrote: Hello, developers. I have a small product "PackageBuild" in my projects, I use it to generate the package_build_info file. [ ... ] When I open the project in QtC 7 the file package_build_info is successfully created, but after the build process starts the file package_build_info is deleted. I cannot reproduce this. Note, however, that you should not keep untracked non-temporary files in the build directory. Generally, it should contain only proper artifacts created by rules. Of course I don't know the specifics of your project, but I have a suspicion that a configure script is not the right place to do whatever it is you are doing there. Christian ___ 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
On 5/2/22 18:27, Карелин Павел wrote:
I am using the construct:
Product {
name: "SharedLib"
property var exportIncludePaths: [
"./",
"./shared",
]
Export {
Depends { name: "cpp" }
cpp.includePaths: product.exportIncludePaths
}
}
Just use this as-is, except with exportingProduct in the Export item.
Export {
Depends { name: "cpp" }
cpp.includePaths: [exportingProduct.cpp.includePaths]
}
I'm not entirely sure, but this might use the merged value, potentially
pulling in more paths than you want. Using a dedicated property seems
cleaner.
Christian
___
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
On 4/29/22 17:27, Карелин Павел wrote: [ ... ] Now the compiler does not see the header file "shared/list.h" from the SharedLib dependency. How to fix the problem? You are likely using "product" in SharedLib's Export item where "exportingProduct" should be used. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Qbs 1.22.1 released
Hi, we have released qbs 1.22.1 today. As usual, sources, binaries, change log etc can be found here: https://download.qt.io/official_releases/qbs/1.22.1/ This release contains a number of important bug fixes (see https://download.qt.io/official_releases/qbs/1.22.1/changes-1.22.1.md). Particularly relevant for Mac users is the support for Xcode 13.3. This release of qbs is also part of Qt Creator 7.0.1. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Qbs 1.22 released
We have released qbs 1.22.0 today. As usual, sources, binaries, change log etc can be found here: https://download.qt.io/official_releases/qbs/1.22.0/ This release of qbs is also part of Qt Creator 7.0.0. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Branch 1.22 created
On 2/15/22 20:18, Björn Schäpers wrote:
Am 15.02.2022 um 17:08 schrieb Christian Kandeler:
On 2/15/22 16:54, Björn Schäpers wrote:
You could mention *explicitly* that the meaning of product within an
Export has changed.
I have a lot of
Export {
...
cpp.cxxLanguageVersion: product.cpp.cxxLanguageVersion
}
And that blew on me. I've found out that I should use
exportingProduct, but maybe ease the use for others.
Note that the deprecation started in 1.18:
https://download.qt.io/official_releases/qbs/1.18.0/changes-1.18.0.md
Okay, did not notice it back then.
I'm not complaining. Just something I stumbled upon.
I was reasonably sure we made an extra announcement for that, but I
failed to find anything. So it seems that was just forgotten.
Anyway, that's exactly what this branching announcement is for, to make
people aware of such issues in time before the release.
Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Branch 1.22 created
On 2/15/22 16:54, Björn Schäpers wrote:
You could mention *explicitly* that the meaning of product within an
Export has changed.
I have a lot of
Export {
...
cpp.cxxLanguageVersion: product.cpp.cxxLanguageVersion
}
And that blew on me. I've found out that I should use
exportingProduct, but maybe ease the use for others.
Note that the deprecation started in 1.18:
https://download.qt.io/official_releases/qbs/1.18.0/changes-1.18.0.md
Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] Branch 1.22 created
Hi, we branched off Qbs 1.22 today. Scheduled release date for version 1.22.0 is end of March (together with Qt Creator 7.0). We recommend users to try this branch with their projects and report back any new problems they find. 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. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Exporting Dependencies on generated files
On 11/12/21 20:33, Björn Schäpers wrote: This should work if you include "hpp" in the type of the generating product. Adding "hpp" as type does indeed result in the complete compilation of the generating product, before the using product is started. But the files were not recompiled if there were changes, so this only helps in the initial build. There is no difference between initial and subsequent builds in this regard. > What was I needed is also to Export cpp.treatSystemHeadersAsDependencies: true. That's an unrelated property that's not relevant for headers that are artifacts of the project. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Exporting Dependencies on generated files
On 11/4/21 11:22, Björn Schäpers wrote:
we have a static library which uses Protobuf, thus generates the
headers, and compiles the code directly into it.
Static Library {
...
Export {
Depends { name: "cpp" }
Depends { name: "protobuf.cpp" }
cpp.systemIncludePaths: [product.protobuf.cpp.outputDir]
}
}
And some products which depend on that, but qbs does not order files
of the dependent products which include the generated headers after
the generation of these.
Is there a way to ideally make the files which include to depend on
the header generation, or at least block all actions on the dependent
product wait until the static library is build?
This should work if you include "hpp" in the type of the generating product.
Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Depending on binary from install-root
On 9/9/21 1:25 PM, Jochen Becher wrote: thank you for the prompt answer. Adding explicit dependency on "installable" works. But adding the input dependency on application does not: The rule uses inputs: [ "alang"] to depend on the alang source code files. When I add additionally inputsFromDependencies: [ "application" ] it doesn't work. inputs["application"] is always undefined. There's almost surely something wrong in one of your rules/products then. You will probably find out what it is if you try to create a minimal example. Seems like inputs and inputsFromDependencies are mutual exclusive. Definitely not, as that's exactly what e.g. the rule creating applications has, where the inputs are object files and the inputs from dependencies are (import) libraries. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] qbs 1.19.2 released
https://download.qt.io/official_releases/qbs/1.19.2/ ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] (no subject)
On 4/6/21 10:58 AM, Dan Pat wrote: Hello. A bunch of Products must be built using a certain set of "cpp" flags. I created a special Module (later referred to as "CppFlags"") containing those flags and had these Products depend upon CppFlags. There are other Modules that the Products depend on, and some of these Modules contain Rules that generate cpp files, which also must be built using the above mentioned set of "cpp" flags. But it seems that since such generator Modules do not explicitly depend on CppFlags, they do not pick up the required flags. So the question is how do I make sure that a certain set of flags is applied to any cpp file built in the context of a Product? If you really assign to cpp properties in your flags module, then these values should be visible anywhere in the product, as there is only one instance of the cpp module. If they are not, you'll need to provide a complete minimal variant of your project, so we can see what is going on. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Build and run a AuxiliaryApplication before build a MainApplication
On 2/19/21 5:43 PM, Карелин Павел wrote:
Project QGit__micro is attached.
The situation is reproduced
I've attached the corrected qbs files.
Christian
import qbs
import qbs.File
import qbs.FileInfo
Product {
name: "QGit"
targetName: "qgit"
type: "application"
destinationDirectory: "./bin"
Depends { name: "cpp" }
Depends { name: "GenTrigrams" }
Depends { productTypes: ["trigrams-generator"] }
Depends { name: "Qt"; submodules: ["core", "widgets"] }
Group {
fileTags: "trigrams"
files: FileInfo.joinPaths(product.sourceDirectory,
"spellcheck/sonnet/trigrams/*")
}
Group {
fileTagsFilter: ["trigrams-map"]
fileTags: ["qt.core.resource_data"]
}
Qt.core.resourceFileBaseName: "trigrams"
Qt.core.resourcePrefix: "trigrams"
Rule {
id: idtrigrams
inputs: ["trigrams"]
explicitlyDependsOnFromDependencies: ["trigrams-generator"]
Artifact {
fileTags: ["trigrams-map"]
filePath: FileInfo.joinPaths(project.buildDirectory, "trigrams",
input.baseName + ".tmap")
}
prepare: {
var runUtl = explicitlyDependsOn["trigrams-generator"][0].filePath
var outputFile = FileInfo.joinPaths(project.buildDirectory,
"trigrams", input.baseName + ".tmap");
//console.info("=== runUtl ===");
//console.info(input);
//console.info(inputs);
//console.info(runUtl);
//console.info(input.filePath);
//console.info(outputFile);
var cmd = new Command(runUtl, [input.filePath, outputFile]);
cmd.description = "sonnet parse trigrams";
cmd.highlight = "filegen";
return cmd;
}
}
files: [
"qgit.cpp",
]
//property var test: {
//console.info("=== Qt.core.version ===");
//console.info(Qt.core.version);
//console.info("=== VERSION_PROJECT ===");
//console.info(project.projectVersion[0]);
//}
}
import qbs
import qbs.FileInfo
Product {
name: "GenTrigrams"
targetName: "gentrigrams"
condition: true
//type: "application"
type: ["application"]
destinationDirectory: "./bin"
Depends { name: "cpp" }
Depends { name: "Qt"; submodules: ["core"] }
cpp.defines: project.cppDefines
cpp.cxxFlags: project.cxxFlags
cpp.cxxLanguageVersion: project.cxxLanguageVersion
// This declaration is needed to suppress Qt warnings
cpp.systemIncludePaths: Qt.core.cpp.includePaths
files: [
"gentrigrams.cpp"
]
Group {
fileTagsFilter: "application"
fileTags: "trigrams-generator"
}
}
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] (no subject)
On 1/11/21 9:23 AM, Dan Pat wrote: Hi. I have a question about making third-party libraries available/visible when running programs from qtcreator. We have a number of prebuilt libraries in the source tree which are currently wrapped in Modules. The modules contain include/library paths, so any depending products build fine, but fail to run because the runtime is unable to locate the library files. One way (our current approach) to solve the problem is to list those files in Modules under Group items, make them installable to "install-root" location and make that location searchable by the dynamic linker (under Windows it is the default behaviour). It works but leads to an inconvenience - these files now show up as being part of the depending products. I know that this is by design, but in this case library files being listed N times in N dependent products look strange at the least. Can anyone recommend a nicer approach? In the groups containing the library files, set the filesAreTargets property to true. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Qt6 support
On 12/4/20 10:44 AM, Maximilian Hrabowski wrote:
Is Qt6 already supported by qbs?If so which version is required? Doing
a naive “Depends { name: “Qt.core5compat” } with abs 1.17 did not work ;)
In general, everything should work out of the box. All problems observed
so far have been on the Qt side, as a fallout of the switch to cmake.
They have been/are being fixed. The last time I checked, Windows was
broken due to a prl file problem, but Linux should work with the current
Qt RC.
There is no specific support for the core5compat module, nor does there
need to be one. If it's there, it will get picked up.
Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Using Parameter
On 12/1/20 8:48 AM, Björn Schäpers wrote:
I've tried to create a product which sets compiler warnings (because
cpp.warningLevel: "all" is not enough), and I want to be able to opt
in some more warnings. I found "Parameter" but I have no idea how to
use it.
I don't think this is what parameters are for. You should just declare
option1 and option2 as normal properties in the Export item and set them
in the product:
Export {
Depends { name: "cpp" }
property bool option1: ...
property bool option2: ...
Depends { name: "All Warnings"; option1: true }
Depends { name: "All Warnings"; id: all_warnings }
all_warnings.option1: true
(As you can see, for syntactical reasons such products should preferably
get names that are valid identifiers.)
Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Environment with AutotestRunner
On 12/1/20 8:59 AM, Björn Schäpers wrote: I'm developing on Windows and have a 64 Bit Qt in my path, but because the linker in 64 Bit mode is much slower than its 32 Bit counterpart I often develop in 32 Bit. If I run the programs directly from the Creator everything is fine. If I click build for the AutotestRunner it seems that the environment is not correctly set. While it loads correctly the 32 Bit runtime (which is also not on the non modified path) the Qt path is not added and it only finds the 64 Bit Qt5Core.dll (which fails to load). Who is at fault, qbs, QtCreator, or I (something not correctly configured)? The AutotestRunner does not set up the environment automatically (like "qbs run" does). You need to do that yourself. See tests/tests.qbs in the qbs repository for an example. Christian ___ 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
On 10/19/20 8:26 PM, Карелин Павел wrote:
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).
Yes, because qmake was found in the PATH. Toolchains work the same way.
If you don't explicitly set the respective property, auto-detection
kicks in.
Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Issues building for Android
On Mon, 12 Oct 2020 16:20:44 +0200 Ola Røer Thorsen wrote: > Compiler feature detection failure! > The command > "/home/olathorsen/Android/Sdk/ndk/21.1.6352462/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ > -x c++ -E -dM -target arm-linux-androideabi -target '' -fPIC -std=c++14 -" > terminated with exit code 1. > error: unknown target triple 'unknown', please use -triple or -arch Do you have qbs.architectures set in your project? You could try setting it to some permutations of the supported set (as printed by the quoted Qt detection code), and see whether they all fail or just e.g. the ARM one. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Issues building for Android
On Mon, 12 Oct 2020 15:07:14 +0200 Ola Røer Thorsen wrote: > The process '/Android/Sdk/build-tools/aidl' could not be started: > execve: No such file or directory. Looks like Android.sdk.buildToolsVersion is empty. Please verify. However, I think this should have resulted in an error message from the respective Probe. Are you sure your project loaded without warnings? What if you set "Force Probes" in the build settings? Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Specify custom applications and application arguments in qbs project
On Mon, 21 Sep 2020 13:15:58 + Jochen Ulrich wrote: > PS: And if you want to run an executable which is built as part of your > project, then the product should of course depend on that executable to make > sure it is built before. Yes. > And the rule should use the executable's `Product.targetName` and ` > Product.destinationDirectory` properties to determine the path of the > executable. No. Instead, the rule should take "application" (or a more unique tag if necessary) as "explicitlyDependsOnFromDependencies" and access the executable via the artifact, i.e. "explicitlyDependsOn.application[0].filePath". Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] dependency tracking
On Tue, 15 Sep 2020 22:10:13 +0500 Dan Pat wrote: > "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. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] dependency tracking
On Mon, 14 Sep 2020 19:11:41 +0500 Dan Pat wrote: > Hi, I have a code generator using C++ *.h headers as its input. Everything > works fine for me except for dependency tracking. Since inputs are ordinary > include files they often include other include files which include other > include files etc. The problem is that when an include file included by the > input file changes the generator is not rerun, because, I guess, it knows > nothing about it. It should, as the scanning is recursive. If you can provide an example project, you could file a bug report. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] How to use texttemplate module?
On Wed, 9 Sep 2020 00:24:36 +0300
Alberto Mardegan wrote:
> Of course, in my project the product type is not "text"
But it has to be, or at least appear as a dependency of the product type
somewhere.
Otherwise there's no path from the source artifact to the product type.
A detailed explanation is here:
https://doc.qt.io/qbs/qml-qbslanguageitems-rule.html#rules-and-product-types
In your concrete product, just add something like this:
type: base.concat("text")
Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] How to get the full dependency name in a ModuleProvider?
On Thu, 30 Jul 2020 23:32:11 +0300
Alberto Mardegan wrote:
>I started playing with ModuleProvider, and I find the "name" property
> a bit confusing: if the dependency was specified as
>
> Depends { name: "myprovider.a" }
>
> the the module provider in "module-providers/myprovider/provider.qbs"
> only sees "myprovider" as "name" property -- the "a" is lost.
>
> But "a" is, in my case, the important bit of information, because I need
> to look up some files in the filesystem based on which dependency is
> specified. Looking at the QBS source code
> (src/lib/corelib/language/moduleloader.cpp), it does not look like there
> is any way to get the full dependency name.
>
> Did I overlook something? If not, would you consider the addition of a
> "relativeName" property, which QBS would set to the second part of the
> name (the one currently being left out, that is "a" in this example), if
> I provide the code for it?
There's probably no harm in adding a "fullName" property containing the string
from the Depends item. Possibly it could even be the value of "name", but I'd
have to take a closer look to determine what makes more sense semantically.
Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Rule.Return dynamic list for outputArtifacts
On Thu, 23 Jul 2020 14:13:13 +0300 Карелин Павел wrote: > Having weighed all the "pros" and "cons", I have decided not to use > qbs.Process in outputArtifacts. Now I settled on a stupidly-simple > solution: I reduced the number of generated files from 6 to 5. But how do you know there will never be fewer than that? Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Rule.Return dynamic list for outputArtifacts
On Tue, 21 Jul 2020 18:32:10 +0300 Карелин Павел wrote: > How can I execute Command from outputArtifacts? You can't, you need to use a JavaScript command and qbs.Process. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Rule.Return dynamic list for outputArtifacts
On Tue, 21 Jul 2020 15:10:38 +0300 Карелин Павел wrote: > I recently needed to develop a rule for a sip generator (see below). > Basically, the rule works well, but yesterday it failed. At the output, > sip-generator create 6 cpp-files of the following format: > sip_corepartX.cpp (this is justified from the point of view of parallel > compilation, cpp-file sizes can be tens of megabytes). These 6 cpp-files > are reflected in the outputArtifacts parameter. 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? Do I understand you correctly that you don't really know in advance how many files will be generated, i.e. the -j parameter just specifies a maximum? Then you either need to find a way to find out the value beforehand (by analyzing the input in some way), or, if that is not possible, you cheat and call the tool already in the outputArtifactsScript; the prepare script then just sets up a dummy command. Note that this loses concurrency, as rule execution happens in the main thread. But this might be acceptable for short-running tools. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Applying cxxFlags to certain files
On Fri, 10 Jul 2020 16:42:51 +0500 Dan Pat wrote: > I have checked out the solution and discovered an inconvenience. As it > stands, Artifacts are passed to the "cpp" module with flags set by the > Product (and product imported Modules) in the context of which the > Artifacts are built. But as soon as I set the Artifact specific > "cpp.cxxFlags" , they seem to replace, instead of being appended to > (desired behaviour), the Product-wise flags. Right, list properties are overwritten, not appended to. Groups behave the same way. > Can you suggest any clean way to deal with this? cpp.cxxFlags: product.cpp.cxxFlags.concat([/*artifact-specific stuff*/]) Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Products with Space in Name
On Fri, 26 Jun 2020 13:14:11 +0200
Björn Schäpers wrote:
> DynamicLibrary {
> name: "FooBar"
> }
>
> CppApplication {
> Depends { name: "cpp" }
> Depends { name: "FooBar" }
> cpp.defines = ["FOO_PATH=\"" + FooBar.buildDirectory + "\""]
Eww... This works? You cannot rely on that, these properties are conceptually
private. Please use exports instead:
DynamicLibrary {
name: "FooBar"
Export { property string theDir: product.buildDirectory }
}
CppApplication {
Depends { name: "cpp" }
Depends { name: "FooBar" }
cpp.defines = ["FOO_PATH=\"" + FooBar.theDir + "\""]
}
> Does not work:
> DynamicLibrary {
> name: "Foo Bar"
> }
>
> CppApplication {
> Depends { name: "cpp" }
> Depends { name: "Foo Bar" }
Depends { name: "Foo Bar"; id: foobar }
cpp.defines = ["FOO_PATH=\"" + foobar.buildDirectory + "\""]
Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Evaluation of Conditional Depends
On Wed, 10 Jun 2020 11:37:02 +0200 (CEST) "Richard Weickelt" wrote: > ... 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? Well, there was no use case so far, and it does seem a bit dubious at first glance. But if there's a compelling case, perhaps it could be added (if it is actually possible; it's been a while since I've done work in that area). Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Evaluation of Conditional Depends
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. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] isystem with clang
On Wed, 20 May 2020 22:11:20 +1200 Christian Gagneraud wrote: > Couldn't find any definite answer about using '-isystem' to avoid the > compiler to report warning as error in 3rd party headers (qt, gtest, > ...). > Looking at the cpp module, i can see some logic, but I can't seem to > find a way to force the use of isystem. > The only suggestion I found was to hack Qt's modules to change > cpp.includePath to cpp.systemIncludePath. > > Is this still the case, or am i missing something? Not sure what you mean. Use cpp.systemIncludePaths for things under your control. For Qt, the respective patch was rejected for some strange reason; see https://codereview.qt-project.org/c/qbs/qbs/+/90492. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Set cpp properties for generated cpp files (moc) does not seem to work
On Wed, 20 May 2020 21:44:46 +1200 Christian Gagneraud wrote: > On Fri, 15 May 2020 at 03:12, Christian Kandeler > wrote: > > > > On Thu, 14 May 2020 14:49:25 + > > Maximilian Hrabowski wrote: > > > > > Isn’t unmocable used to tag cpp/header files that should not be processed > > > by moc? > > > > Sure, that's why the generated cpp files get it, so they won't get > > processed again. > > Is there a similar tag for precompiled qml? No, here the inputs are not C++, so no loop prevention is necessary. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Set cpp properties for generated cpp files (moc) does not seem to work
On Thu, 14 May 2020 12:22:53 +
Maximilian Hrabowski wrote:
> we have quite a strict warning policy so all warnings are treated as errors
> in our code. This creates problems when including third-party code that
> produces warnings, so usually those files are put in a special group and
> warningsAreErrors is turned off:
>
> Group {
> …
> cpp.treatWarningsAsErrors: false
> }
>
> This usually works quite well. But now i’ve got the problem that i need to
> disable this for cpp files generated by moc. I tried the following approach
> but it does not seem to work:
>
> Group {
> fileTagsFilter: [“moc_cpp"]
"moc_cpp" is for files to be included. As those won't get compiled, this
property has no effect.
You might be able to approximate what you want by using "unmocable" here.
> cpp.treatWarningsAsErrors: false
> }
Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Undocumented SubProject.condition property
On Thu, 16 Apr 2020 11:57:08 + Jochen Ulrich wrote: > We found that there is an undocumented `condition` property on SubProject > items. > It seems to have the same effect as setting the `condition` property inside > the Properties block. > However, I find it more readable to have the condition on the SubProject > instead of inside the Properties block. > > So the question is: what's the state of this undocumented property? > Should it be made official and be documented or is it deprecated and will > possibly be removed? I think the property makes sense, if only because most items have one and there is no good reason for this one to be different. Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] building android aab package help
[Redirecting back to the mailing list] On Thu, 16 Apr 2020 20:17:47 +0200 Raphael Cotty wrote: > Le mer. 15 avr. 2020 à 09:48, Christian Kandeler > a écrit : > > > Building an aab is similar to building apk. They both take the same inputs > > > (including java files) and generate a java file (R.java) but in a > > different > > > way. > > > > > > I first tried to add the android.aab type to the product type property in > > > order to build both types. > > > But I can't find a way to redirect all java files + the R.java apk to the > > > next apk rule and all the java files + R.java aab to the next aab rule > > > (without changing the java module). > > > > I don't understand this part. What is a "next rule"? What do you mean by > > "redirect"? > > If I could duplicate the java modules I'd do this: > I'd tag all java files in the product to java.java-apk and java.java-aab. > The the R.java generated for apk will be tagged java.java-apk > The the R.java generated for aab will be tagged java.java-aab > > One copy of the java modules will have this rule: > [java.java-apk] => [java.class-apk] > The other copy: > [java.java-aab] => [java.class-aab] > > I'd also have 2 rules for the dex step (identical prepare script) > [java.class-apk] => [dex-apk] > [java.class-aab] => [dex-aab] > > Then the 2 final steps (different prepare script): > [dex-apk] => [apk] > [dex-aab] => [aab] > > That's obviously horrible. But that shows the 2 paths. > > But can this be done with qbs without to duplication of code? The answer depends on my earlier question you did not answer: > > And what is the apk/aab "context"? > > Are you saying you need to build both the APK and the AAB file? If so, > > what is the relationship between them? Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] building android aab package help
On Tue, 14 Apr 2020 21:27:18 +0200 Raphael Cotty wrote: > I am struggling to find a way to build the aab package (non runnable > package required by google store) on the android platform. > For this platform the default qbs product type is changed from application > to android.apk (runnable package). > What I am trying to achieve is allowing the user to just set a property in > his project to enable the build of the aab package: Note that the property should most probably be in the Android.sdk module instead. > Building an aab is similar to building apk. They both take the same inputs > (including java files) and generate a java file (R.java) but in a different > way. > > I first tried to add the android.aab type to the product type property in > order to build both types. > But I can't find a way to redirect all java files + the R.java apk to the > next apk rule and all the java files + R.java aab to the next aab rule > (without changing the java module). I don't understand this part. What is a "next rule"? What do you mean by "redirect"? > // Let's gather all compiled java classes and generate the > classes.dex > // If running in the apk context then we have all project java > classes and the > // R.java generated in the apk context > // If running in the aab context then we have all project java > classes and the > // R.java generated in the aab context And what is the apk/aab "context"? Are you saying you need to build both the APK and the AAB file? If so, what is the relationship between them? Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Binary stripping
On Thu, 9 Apr 2020 22:49:48 +0300 Alberto Mardegan wrote: > I noticed that binaries generated by mingw are quite large, and when I > ran the "strip" command on them, the size was reduced by more than half, > without losing functionality. > > I'm building my application with the `config:release` option. Shouldn't > that run "strip" on the generated binaries? I see that QBS seems to be > strip-aware already (there are the stripName and stripPath options in > the cpp module), but it appears that their usage is only triggered if > separate debug information is requested. > > Is there a reason why "strip" is not invoked when in release mode? This has come up before, and I vaguely remember there was some counter argument, but I don't kow anymore what it was. Anyway, qmake, I believe, runs strip for mingw only (perhaps because of the extreme code size issues mentioned above?). What do other build tools do? Christian ___ 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
> I think you should write:
> CppApplication {
>name: "app"
>files: ["gen.cpp"]
>Depends { name: "lib"; profiles: "targetProfile" }
> }
Ah right, I completely forgot about that property...
___
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
On Fri, 20 Mar 2020 16:01:09 + Leon Buckel wrote: > 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 I assume this is from when you built the build tool for the target platform? Otherwise, the message would be the wrong way around. Anyway, if you check the command line, do both versions of the library appear there or just the wrong one? Also, is the behavior different between qbs 1.15 and 1.16? Christian ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
