[Qbs] Could we make a version 1.24.2?
Hi there! I have a handful of projects using the freedesktop qbs module, with a line like this: freedesktop.name: product.name This does not work in QBS 2.x, because the "name" property was renamed to "appName". Now that I'm moving over to QBS 2.x, I've still the issue that in some cases I still need to compile my projects with QBS 1.x (updating these setups to a 1.24.2 would be simpler than updating to 2.x, since in 2.x the build system has changed and qmake is no longer supported), so I need a solution that works in both systems. Hence my question: can we backport the appName change to QBS 1.x and make a release? Ciao, Alberto ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Running the target through a wrapper
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? 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). 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
Re: [Qbs] QBS for Ubuntu LTS releases and docker images
Добрый день, Павел! On 02/06/22 13:14, Карелин Павел wrote: It's too bad the core developers of QBS didn't do this sooner. Now the fresh compiled version of QBS can only be downloaded as an archive (and in my country even this cannot be done now). I happen to live in the same country :-) Not that this was a problem for me, but as an indirect sign of the immaturity of the product, there is a place to be. Sometimes I hear such reproaches among my colleagues. Alberto, will the repository work for ARM-platforms? Or only Amd/Intel? The docker images are only AMD/Intel, but of course can be used to cross-compile if the right toolkit is provided. The QBS builds on the Launchpad PPA are built for amd64, i386, armhf and arm64. So, given that the sources for the Docker images are public (see https://github.com/mardy/docker-images), I believe i should be easy to generate docker images for other architectures. In my experience, however, cross compiling is always faster. Ciao, Alberto ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] QBS for Ubuntu LTS releases and docker images
Hi all! In case this is of interest to somebody else than me: I've recently updated my Ubuntu PPA containing QBS 1.22.1 for Ubuntu Xenial, Bionic, Focal and Jammy: https://launchpad.net/~mardy/+archive/ubuntu/qbs-on-lts Except for Jammy, QBS is linked statically, without using the Qt provided by the distribution (which is too old). Also, I have a few Docker images with Qt 5.15, QBS 1.22.1 and cmake: https://hub.docker.com/repository/docker/mardy/qt (these can be used on Gitlab CI, for example). 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
Re: [Qbs] Strange error with QBS 1.22.1 on Android
On 24/05/22 23:31, Alberto Mardegan wrote: Here's the error: https://pastebin.com/68KdfagX Oh, I see it now, there's a lonely "-D" in the compiler command line: ... -DXDG_THUMBNAILS -D -DQT_SVG_LIB ... 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? At least, 1.16 seemed to handle that and did not add a "-D". Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Strange error with QBS 1.22.1 on Android
Hi all, I upgraded to QBS 1.22.1 and I get a very weird errorwhen building on Android (Qt 5.15.2); the build for Linux desktop (x86_64) instead works fine. Here's the error: https://pastebin.com/68KdfagX The source code is https://gitlab.com/mardy/mappero/-/commits/qt5.12 I should also point out that this QBS is a version I've built myself against a static Qt (the Ubuntu Focal one from https://launchpad.net/~mardy/+archive/ubuntu/qbs-on-lts/+packages), if that matters (with the same QBS the desktop version builds fine). Any hints? 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
Re: [Qbs] Selecting target architecture for Android
Hi Christian, On 23/05/22 11:12, Christian Kandeler wrote: 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. I do have an "install: true" on the library product, indeed. But I thought this was needed to have the library installed on Linux? NDK ABI name and qbs architecture name are not always the same. I suppose qbs.architecture would be armv7a here. Ah, you are right, thanks! This got me a bit further; I'm getting another error now, but before bothering you with that I want to try with the latest QBS version (I am using 1.16, and I see that several things have changed in regard to Android builds since then). 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
Re: [Qbs] Selecting target architecture for Android
Hi Rafael, On 23/05/22 13:38, Raphael Cotty wrote: Hello, the libMapperoCore.so should have the architecture name like this: libMapperoCore-arch.so What type of product do you use for the MapperoCore? It's a DynamicLibrary. Is there something special which I should do to give the compiled library that name? Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Retrieving project options
Hi again :-) Sorry for the spamming, this hopefully is an easy question: 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? Like, if I ran: qbs run profile:android515 project.geotagger:false -f .. I would like to be able to see the options profile:android515 project.geotagger:false (at least -- seeing the whole command line would also be fine) Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Selecting target architecture for Android
Hi there!
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.
==
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:
===
Build graph does not yet exist for configuration 'default'. Starting
from scratch.
Resolving project for configuration default
Setting up Qt at '/home/mardy/Qt/5.15.2/android//bin/qmake'...
Qt with multiple abi detected: 'armeabi-v7a,arm64-v8a,x86,x86_64'
Configuring abi 'armeabi-v7a'...
Configuring abi 'arm64-v8a'...
Configuring abi 'x86'...
Configuring abi 'x86_64'...
Qt was set up successfully.
ERROR: /home/mardy/src/git/mappero/lib/Mappero/Mappero.qbs:3:1 Error
while handling product 'MapperoCore':
/home/mardy/src/git/mappero/lib/Mappero/Mappero.qbs:62:5 Module Qt.core
could not be loaded.
/home/mardy/src/git/mappero/lib/Mappero/Mappero.qbs:63:5 Module Qt.gui
could not be loaded.
[...]
===
How do I tell QBS to just use a single architecture for Android? If
possible, I'd like doing that from the command line, since the project
is multi platform and I wouldn't like to clobber the QBS project file
for this.
Thanks to whoever can help!
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
Re: [Qbs] Build and run a AuxiliaryApplication before build a MainApplication
On 11/02/21 10:58, Карелин Павел wrote: > But then I found out that the assembly of the project depends on the > order of declaring sections 'Depends' Unfortunately I don't have a recent enough version of QBS (still at 1.16), so I'm unable to try your project, but can you please paste the error you get this time? Does the SharedLib depend on the generator, or on resource files? 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
Re: [Qbs] Build and run a AuxiliaryApplication before build a MainApplication
Just got some more thoughts:
On 10/02/21 11:48, Карелин Павел wrote:
> --- parsetrigrams.qbs ---
> import qbs
> import qbs.FileInfo
>
> Product {
> name: "SonnetParseTrigrams"
> targetName: "sonnet_parsetrigrams"
> condition: true
>
> type: "application"
You can add an additional type here, like
type: ["application", "trigram-generator"]
And then:
> --- qgit.qbs ---
> import qbs
> import qbs.FileInfo
>
> Product {
> name: "QGit"
> targetName: "qgit"
>
> type: "application"
> destinationDirectory: "./bin"
>
> Depends { name: "cpp" }
> Depends { name: "SonnetParseTrigrams" }
> Depends { name: "Qt"; submodules: ["core", "widgets"] }
Here add
Depends { productTypes: ["trigram-generator"] }
and in your Rule add
explicitlyDependsOnFromDependencies: ["trigram-generator"]
I'm not 100% sure that the last one is needed, but it seems to make
sense :-)
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
Re: [Qbs] Build and run a AuxiliaryApplication before build a MainApplication
On 10/02/21 11:48, Карелин Павел wrote:
> Group {
> fileTagsFilter: ["trigrams-map"]
> //fileTagsFilter: ["sonnet-parse-trigrams-run"]
> fileTags: ["qt.core.resource_data"]
> }
Does it help if you remove this Group and instead add
outputFileTags: "qt.core.resource_data"
to your Rule?
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
Re: [Qbs] How to use texttemplate module?
On 09/09/20 11:25, Christian Kandeler wrote:
> 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")
Thanks!
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?
Ciao,
Alberto
--
http://www.mardy.it - Geek in un lingua international
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] How to use texttemplate module?
Hi all,
I'm having some trouble using the texttemplate module, because I
cannot get its rule to execute.
If I run the test file from
https://code.qt.io/cgit/qbs/qbs.git/tree/tests/auto/blackbox/testdata/texttemplate
then everything works.
But if I modify that file and change the Product type from "text" to
"application", then the rule is no longer run.
I also tried to add
Group {
fileTagsFilter: ["text"]
qbs.install: true
}
to the QBS file, but still the texttemplate rule is not executed. Of
course, in my project the product type is not "text" (I have a
QtGuiApplication), so how can I tell QBS that it should run all the
rules which produce a "text" artifact?
Ciao,
Alberto
--
http://www.mardy.it - Geek in un lingua international
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] How to get the full dependency name in a ModuleProvider?
On 31/07/20 11:03, Christian Kandeler wrote: > 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. Maybe we can keep "name" the way it is (after all, it's the name of the ModuleProvider, so it kind of makes sense that it matches its location) and add a "dependencyName" property containing the full dependency name. Incidentally, the following properties of the Depends item could also be very useful to the module provider: submodules : stringList versionAtLeast : string versionBelow : string maybe, then, it would make more sense to add a "dependencyInfo" property as an object containing the three properties above, and the original "name" from the Depends directive? 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
Re: [Qbs] How to get the full dependency name in a ModuleProvider?
Il 31.07.2020 11:28, Jochen Ulrich ha scritto: We also stumbled over this and a few more shortcomings of ModuleProviders when writing a ModuleProvider to integrate the Conan package manager with Qbs. See this thread: https://lists.qt-project.org/pipermail/qbs/2020-February/002649.html Interesting! You didn't find these as issues in JIRA< did you? At least, I couldn't find them out of a quick search. Ciao, Alberto ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] How to get the full dependency name in a ModuleProvider?
Adding one more question, to make sure I do not misunderstand the role
of a ModuleProvider:
Il 30.07.2020 23:32, Alberto Mardegan ha scritto:
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.
why does the ModuleProvider name contain a piece of data which is anyway
known to the ModuleProvider (because it's anyway encoded in its file
path)? What is the point of this property?
Ciao,
Alberto
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] How to get the full dependency name in a ModuleProvider?
Hi again!
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?
Ciao,
Alberto
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Building a product's files into another product
Hi Ulrich,
Il 30.07.2020 14:04, Jochen Ulrich ha scritto:
Hi Alberto!
Did you try using a Module instead of a Product?
Not yet, because it would require some deeper refactoring of my QBS
project, but:
Or export from a Product (which also creates a Module internally):
yes, this is almost working. As a matter of facts, it indeed works for
the example I posted before, but my problem is that the source files are
generated at build time (by the Qt resource system), and it looks like
they are not being picked up by the Group:
Export {
Group {
fileTagsFilter: ["cpp"]
}
}
I will experiment a bit more with the QBS.Exporter module, because it
might be exactly what I'm looking for (or maybe I'll just got for a
module, as you suggested!).
Ciao,
Alberto
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] Building a product's files into another product
Hi!
The subject is a bit convoluted, but the meaning is this one: I have
product A defined like this:
Product {
type: "linkme"
name: "a"
Depends { name: "cpp" }
files: ["one.cpp"]
}
(in reality, the situation is more complex than this and the input files
are static files with the "qt.core.resource_data" tag, which causes a
"qrc_a.cpp" to be generated)
And I'm trying to use it from a product B:
CppApplication {
name: "b"
Depends { name: "a" }
...
}
Now, I would like that the cpp files from product A would be used when
building product B, that is as if product A was a Group. But it looks
like the Depends item is not effective.
I also tried to change the product's type to "obj", and this at least
causes the files in product A to be compiled; but they are still not
added to product B.
Indeed, it all works if I change product's A type to "staticlibrary",
but that forces me to use Q_INIT_RESOURCE, which I was trying to avoid.
Any ideas?
(the reason why I'm using a product and not a Group is that, under some
configurations, this could indeed be a separate product like a loadable
module)
Ciao,
Alberto
--
http://www.mardy.it - Geek in un lingua international
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Conditionally adding a file tag
Hi Ulrich,
On 29/07/20 10:07, Jochen Ulrich wrote:
> I guess the issue here is that FileTaggers are disabled in this case:
>
>> File taggers are disabled if file tags are set explicitly in a product or
>> group.
>> For example, the "cpp" tag is not attached to the .cpp files in the
>> following product
> (see https://doc.qt.io/qbs/qml-qbslanguageitems-filetagger.html#details)
It's not clear to me whether this applies to my case too: my group is
not specifying a file list, but it's using the fileTagsFilter to
populate itself. And in the fileTagsFilter documentation it's written (
https://doc.qt.io/qbs/qml-qbslanguageitems-group.html#fileTagsFilter-prop):
"The file tags that the group's fileTags property specifies will be
added to the matching artifacts."
which seems to be exactly my use-case.
> But normally, it is not a problem to set those tags via a Group when
> organizing the Groups accordingly.
> For example you could have a dedicated Group for those resources. Something
> like
>
> Group {
> name: "Resources"
> fileTags: embedAsResource ? ["qt.core.resource_data"] : []
> qbs.install: !embedAsResource
> qbs.installDir: "share/" + project.relativePluginDir
> qbs.installSourceBase: "../"
> files: [
> "file1.qml",
> "file2.qml",
> "file3..png",
> "file4.gif",
> ]
> }
Yes, this would work, but I'm writing a generic QBS item, that's why I
don't want to explicitly list the input files in there.
Ciao,
Alberto
--
http://www.mardy.it - Geek in un lingua international
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] Conditionally adding a file tag
Hi all!
I have a Product consisting of static files (images, QML and JSON);
you can see the base item here:
https://gitlab.com/mardy/mappero/-/blob/fd935d58a55523bf7d6b281f2728f055704a2b26/qbs/imports/QmlPlugin.qbs
and a trivial QBS file in which it's used:
https://gitlab.com/mardy/mappero/-/blob/fd935d58a55523bf7d6b281f2728f055704a2b26/src/plugins/nominatim/plugin.qbs
It all works fine, the static files are installed in the filesystem in
the proper location.
Now, however, I'm building the Android version and I would like to embed
the same file as a resource, but only when building for Android. So,
I've changed the base item like this:
===
Product {
type: embedAsResource ? "staticlibrary" : "qmlplugin"
property bool embedAsResource: true // logic is TODO
Depends { name: "Qt.core" }
...
FileTagger {
patterns: [ "*.png", "*.gif", "*.svg" ]
fileTags: "image"
}
FileTagger {
patterns: "*.qml"
fileTags: ["qml"]
}
Group {
fileTagsFilter: [ "qml", "image" ]
fileTags: embedAsResource ? ["qt.core.resource_data"] : []
qbs.install: !embedAsResource
qbs.installDir: "share/" + project.relativePluginDir
qbs.installSourceBase: "../"
}
===
That is, if the embedAsResource property is true (and it always is,
currently), the product should be a static library, and the
"qt.core.resource_data" tag should be added to the static files.
But the above does not work. It appears that the new tag is not being
added. It all works if I add it directly into the FileTagger items, but
I would rather avoid doing that, since I have several of them and adding
a conditional would make the QBS file harder to read.
So, in short, the question is this: why isn't it possible to use the
Group's fileTags property to add a tag in this case? Or am I doing
something else wrong here?
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
Re: [Qbs] Android and shared libraries in APK
On 11/07/20 13:18, Alberto Mardegan wrote: > I guess that the desired outcome is that there is only one shared > library whose name matches the product.name; is my understanding correct? This appears to be working for me: https://codereview.qt-project.org/c/qbs/qbs/+/307513 Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Android and shared libraries in APK
Hi all, sorry for the week-end spamming :-) My project consists of an executable file and two shared libraries. The Android build is failing right at the end, with this message: ERROR: Qt applications for Android support only one native binary per package. On the other hand, the documentation [1] seems to imply that multiple libraries are allowed: "You can use the DynamicLibrary item to build native Android libraries that are bundled into the APK" I've looked into the QBS code, and I'm not sure I understand the checks being performed there [2] (or better, what their goal is). It looks like that if the first native library found has a name which matches the product name, then one can have as many other libraries as desired; but if the list of libraries contains as the first two elements two libraries whose name does not match the product name, then the exception is thrown. So, I suspect that the code there is wrong, since it depends on the order of the items in the array. But it's not clear to me how to fix it, because I don't understand what should be allowed, and what should not. I guess that the desired outcome is that there is only one shared library whose name matches the product.name; is my understanding correct? Ciao, Alberto [1]: https://doc.qt.io/qbs/qbs-target-android.html [2]: https://github.com/qbs/qbs/blob/master/share/qbs/module-providers/Qt/templates/android_support.qbs#L97-L120 -- http://www.mardy.it - Geek in un lingua international ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Android API level
Hi all,
While trying to build one of my existing projects for Android, I was
getting a build error:
==
In file included from
/home/mardy/Android/Sdk/ndk/20.1.5948944/sources/android/support/include/math.h:32:
/home/mardy/Android/Sdk/ndk/20.1.5948944/sources/cxx-stl/llvm-libc++/include/math.h:1330:93:
error: no member named 'log2f' in the global namespace
inline _LIBCPP_INLINE_VISIBILITY float log2(float __lcpp_x)
_NOEXCEPT {return ::log2f(__lcpp_x);}
...
==
which seemed to be related to the Android API level declared [1].
Indeed, after adding the following lines to my project, it works:
==
Properties {
condition: qbs.targetOS.contains("android")
Android.ndk.platform: "android-21"
}
Depends {
condition: qbs.targetOS.contains("android")
name: "Android.ndk"
}
==
However, there are still a couple of issues not clear to me:
1) In share/qbs/modules/Android/ndk/ndk.qbs, the platform property is
either initialized to "android-19" or "android-21"; how come, then, that
in my project the compiler command line was using "16" as API level?
2) The automatically-generated Android manifest still reports
minSdkVersion="16". I guess I should file a bug for this?
Ciao,
Alberto
[1]: According to another project where the same error was reported:
https://github.com/tensorflow/tensorflow/issues/20192
--
http://www.mardy.it - Geek in un lingua international
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Mingw issues
On 07/04/20 23:04, Richard Weickelt wrote: > 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 > ? Here it is: https://codereview.qt-project.org/c/qbs/qbs/+/296870 I wait on the CI to see whether this breaks something on Windows, since I didn't test Windows myself. :-) Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Binary stripping
Hi all! Sorry for spamming the list :-) 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? 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
Re: [Qbs] Changing the default value of consoleApplication
On 08/04/20 13:21, Oswald Buddenhagen wrote: > i'm not convinced. qt.widgets and qt.quick could reasonably do that, but > gui is perfectly suitable for console-only apps. mmm... you are right, there might be a QtGuiApplication which uses QImage to do some processing but never creates a window. One might still argue that that's not such a common use-case, and that it can anyway be overridden. I'll wait for some more opinions :-) 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
Re: [Qbs] Q_INIT_RESOURCE on Windows
On 08/04/20 00:33, Иван Комиссаров wrote: > From the Qt documentation: > > "The Q_INIT_RESOURCE() macro is necessary on some platforms for > resources stored in a *static* library.» Oops! Sorry for the noise, and thanks for the pointer! :-) Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Q_INIT_RESOURCE on Windows
Hi there!
I was about to write this to the QtProject mailing list, but then I
got the doubt that this might be a QBS issue, so I thought of double
checking with you guys first.
I'm building a GUI application which comes with a shared library which
contains some Qt resources that need to be made available to the
application.
However, on windows the build fails, both natively (you can check the
AppVeyor logs here [1]) and cross-compiled with MXE from Linux. The
error is:
==
main.cpp.obj : error LNK2019: unresolved external symbol "int __cdecl
qInitResources_mappero_ui(void)" (?qInitResources_mappero_ui@@YAHXZ)
referenced in function main
C:\projects\mappero\default\mappero.a4d1648d\mappero.exe : fatal error
LNK1120: 1 unresolved externals
==
The main.cpp files contains Q_INIT_RESOURCE(mappero_ui), and a file
release/MapperoUi.e4550a40/qrc_mappero-ui.cpp
is present in the build directory, and it contains (among a lot of other
stuff) the lines:
==
int QT_RCC_MANGLE_NAMESPACE(qInitResources_mappero_ui)();
int QT_RCC_MANGLE_NAMESPACE(qInitResources_mappero_ui)()
{
int version = 3;
QT_RCC_PREPEND_NAMESPACE(qRegisterResourceData)
(version, qt_resource_struct, qt_resource_name, qt_resource_data);
return 1;
}
==
I checked with the nm tool (provided by MXE), and the dll library indeed
contains the qInitResources_mappero_ui() symbol; however, the symbol is
not present in the MapperoUi.lib file generated in the same directory.
Shouldn't the symbol in the generated qrc_mappero-ui.cpp file be wrapped
in a Q_DECL_EXPORT() macro?
Could it be that this is a qbs bug, that for some reason it does not
invoke rcc with the right options?
Ciao,
Alberto
[1] https://ci.appveyor.com/project/mardy/mappero/builds/31993601
--
http://www.mardy.it - Geek in un lingua international
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] Changing the default value of consoleApplication
Hi there! I've recently built a Windows application with QBS, and was a bit surprised that it was built as a console application (the terminal opened when running it). Would anyone object if I submit a change to the QtGuiApplication item, so that it unconditionally sets the `consoleApplication` property to false? 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
Re: [Qbs] Mingw issues
On 05/04/20 22:48, Richard Weickelt wrote: > Does your toolchain setup work without Qt? Maybe build a plain c++ hello > world app. > > Is the deduced qbs.architecture correct? The architecture is unset (I cannot see it with `qbs config`, at least). But looking at the configuration I understood where the problem was: I didn't set up the base profile correctly: == $ qbs config --list [...] profiles.gcc.cpp.toolchainInstallPath: "/usr/bin" profiles.gcc.qbs.toolchain: "gcc" profiles.mxe-i686-w64-mingw32-static.cpp.toolchainInstallPath: "/mnt/Lavoro/mxe/mxe-qt5.9/usr/bin" profiles.mxe-i686-w64-mingw32-static.cpp.toolchainPrefix: "i686-w64-" profiles.mxe-i686-w64-mingw32-static.qbs.targetPlatform: "windows" profiles.mxe-i686-w64-mingw32-static.qbs.toolchain: ["mingw", "gcc"] profiles.mxe-qt59-i686-w64-mingw32-static.baseProfile: "gcc" profiles.mxe-qt59-i686-w64-mingw32-static.moduleProviders.Qt.qmakeFilePaths: "/mnt/Lavoro/mxe/mxe-qt5.9/usr/i686-w64-mingw32.static/qt5/bin/qmake" [...] == Setting the base profile to "mxe-i686-w64-mingw32-static" made me progress a bit: == ERROR: /home/mardy/src/git/mappero/lib/Mappero/Mappero.qbs:3:1 Error while handling product 'Mappero': /usr/local/share/qbs/imports/qbs/Probes/GccProbe.qbs:56:16 Error: Error running '/mnt/Lavoro/mxe/mxe-qt5.9/usr/bin/i686-w64-g++': execve: No such file or directory == 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`. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Mingw issues
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
Re: [Qbs] Using QBS with an nonexistent $HOME
On 29/02/20 19:17, Wookey wrote: > I have written a wiki page about using QBS to build debian packages: > https://wiki.debian.org/Qbs > > I deal with QBS's desire to store a profile in the home directory by setting > --settings-dir to either /tmp (potential security risk as other can change > your build/config) or --settings-dir $(CURDIR)/debian for package builds. Thanks all, this helped! I'm facing other issues due to some partially broken packaging in Ubuntu (missing qml-private module) and to the lack of features of the QBS version (1.10), but these are all solvable. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international signature.asc Description: OpenPGP digital signature ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Using QBS with an nonexistent $HOME
Hi there! I'm trying to build a Debian/Ubuntu package of a QBS project in launchpad.net; the site uses sbuild, which has the peculiarity of setting "HOME=/sbuild-nonexistent". I'm stuck at the step "qbs setup-qt", which fails with this error: Setting up Qt profile 'qt5' failed: Cannot create directory '/sbuild-nonexistent/.config/QtProject/qbs/1.10.1/profiles/qt5/modules/Qt'. Adding the "--system" option to QBS doesn't seem to help. I guess I could workaround the issue by setting HOME=$PWD, but this partially defeats the point of using sbuild. Is there a better way to solve this? I'm especially curious, because the step "setup-toolchains" doesn't seem to be affected by this 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
Re: [Qbs] Passing paths to properties
On 03/02/20 15:37, Christian Kandeler wrote: >> >> 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. > > https://doc.qt.io/qbs/language-introduction.html#property-types It seems to me, though, that this "path" type is little more than an alias to "string", in that it doesn't have any methods and doesn't seem to be treated specially. Anyway: https://codereview.qt-project.org/c/qbs/qbs/+/289261 I was happy to see that the FileInfo.resolvePath() already exists. :-) It's not documented, however; is there any reason for that, or should we add it to the reference? Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Passing paths to properties
Hi there! I was trying to customize the location of my Android resources within a project, by playing with the resourcesDir and sourceSetDir properties. It took me a while (and a look at the QBS Android.sdk module sources) to realize that I should pass an *absolute* path to these properties. Indeed, prefix these paths with product.sourceDirectory made everything work fine. 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? 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? 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
Re: [Qbs] Error after running tests
On 14/01/20 22:56, Jochen Ulrich wrote: > So instead of > $ qbs run -p check > > you should do > $ qbs build -p check Oh, indeed, I should have known better! :-) Thanks a lot! Ciao, Alberto ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Error after running tests
Hi there!
I'm using the AutotestRunner to run the unit tests in my project [1].
The tests run successfully, but then QBS tries to install them (why?)
and fails:
===
$ qbs project.enableCoverage:true project.buildTests:true
[...]
$ qbs run -p check
Restoring build graph from disk
Building for configuration default
Clearing coverage data [coverage-clean]
Running test path-test [check]
/home/mardy/src/git/mappero/default/path-test.6e444deb/path-test
* Start testing of Mappero::PathTest *
Config: Using QtTest library 5.12.4, Qt 5.12.4
(x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 5.3.1
20160406 (Red Hat 5.3.1-6))
PASS : Mappero::PathTest::initTestCase()
PASS : Mappero::PathTest::loadGpx()
PASS : Mappero::PathTest::loadKml()
PASS : Mappero::PathTest::saveGpx()
PASS : Mappero::PathTest::positionAt()
PASS : Mappero::PathTest::cleanupTestCase()
Totals: 6 passed, 0 failed, 0 skipped, 0 blacklisted, 54ms
* Finished testing of Mappero::PathTest *
Build done for configuration default.
Installing
ERROR: Cannot run: Product 'check' is not an application.
===
("check" is the name of the AutotestRunner item)
It's been a while since I ran the unit tests on this project, but I
don't remember having seen this before.
Is there a way to suppress the installation (or at least to get rid of
the error)?
Ciao,
Alberto
[1]: https://gitlab.com/mardy/mappero
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Qbs 1.15.0 released
Hi Richard, On 02/01/20 14:20, Richard Weickelt wrote: > 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. with the advent of year 2020, we'll eventually need to update the copyright in the source code. Can you please clarify what is the situation, now that (unless I'm mistaken) The Qt Company won't be owning the project anymore? 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
Re: [Qbs] Deployment and dependency bundling
Ho Oswald,
On 27/12/19 21:24, Oswald Buddenhagen wrote:
> you're mixing up two separate issues.
>
> "deployment" (you actually mean dependency embedding) is just a special
> form of "linking" dependencies. you should be able to make a fully
> static build or a bundle with embedded dlls and plugins from the same
> project, by flipping a single bit. similarly, for qml, you could select
> whether the qml files are compiled (with the old qml compiler) or
> embedded as-is.
Yes. But you are describing the ideal world, not the current situation,
right? QBS with Android already works like this, but for the desktop
platforms that's not yet the case (I'm not sure about Windows, but on
Linux and MacOS one still has to run {linux,mac}deployqt).
> _what_ gets depended upon is a policy decision that is independent from
> the mechanism that does the linking.
> plugins specify a type, while modules declare what types of plugins they
> want to pull in. that makes this policy implicit, and a manual override
> is provided. that was actually already implemented for the qt port.
I guess I miss some history here; what do you mean with "qt port"?
[...]
>> * Additional properties could be used to exclude some libraries
>> * from being deployed (because we assume they exist in the
>> * target system).
>> */
>> deployment.excludePatterns: [ "libstdc++.so*", "libxcb.so*" ]
>>
> the embedding property should apply to abstract modules (and their
> "slices", i.e., files that fall into a particular category), not
> os-specific files. yes, that means that there need to be modules for
> "system" dependencies, and they should be declared as such (so that
> projects don't need to repeat the exclusions each time).
In those cases where the exclusions are well-known, yes. But for
AppImage the situation is rather foggy: the list of exclusions is not
defined by any SDK, but it's the result of a trial and error effort,
greatly depending on application developers submitting bug reports; a
look at the history of the excludelist file in the AppImage repository
[1] is enough to understand that we cannot consider it stable, and we'll
always have at least to provide a way to override parts of it.
But I agree, that we should consider this to be an exception rather than
the rule.
What I'm still missing is an understanding of how this would look like
from the point of view of the QBS user: do we agree that the installable
package (MSI, PKG, AppImage, etc.) should be a different Product, or do
we want to generate it when building the Application?
Do we want to expose the different steps (dependency embedding and
generation of the installable package file) to the QBS user (maybe as
two different products?), or should they both happen together?
Ciao,
Alberto
[1]: https://github.com/AppImage/pkg2appimage/commits/master/excludelist
--
http://www.mardy.it - Geek in un lingua international
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Deployment and dependency bundling
On 27/12/19 15:15, Oswald Buddenhagen wrote:
> dependency embedding should be a property of the Depends item (based on
> https://bugreports.qt.io/browse/QBS-585). the way this is actually
> handled is platform-dependent and needs to be properly abstracted
> (https://bugreports.qt.io/browse/QBS-229).
I agree that in many cases the Depends item is the one who has the best
information on how to handle its deployment. For example, the QtGui
module will know which platform plugins need to be deployed, and the
QtQml module could know which QML modules need to be deployed and how.
Solving this probably doesn't seem easy, so in my dumb approach (using
ldd) I was hoping to find a quicker solution that would take care of
solving only part of the problem.
But if we can reach an agreement on how this could look like, jumping to
the implementation will be easier. For the time being I don't have a
clear picture. Maybe we can start by defining how this will look like in
the project file?
Project {
QtGuiApplication {
Depends {
name: "QtGui"
/* Or should this be automatically detected depending on
* the target? Maybe one should have a "deployed-app" product,
* and deployment should be triggered if and only if qbs is
* asked to build that target?
*/
deployment.enabled: product.install
/* The "*plugins" properties are specific to the QtGui
* dependency.
*/
deployment.imageformatsPlugins: ["png", "svg"]
deployment.sqldriversPlugins: ["qsqlite"]
}
Depends {
name: "QtQuick"
deployment.enabled: product.install
/* The "modules", "deduceModulesFrom", "excludeModules" properties
* are specific to the QtQuick and QtQml dependencies.
*/
deployment.modules: ["QtQuick","QtQuick.Controls.Material"]
// deployment.deduceModulesFrom: [ "src/myqmlfiles/*.qml" ]
// deployment.excludeModules: [ "QtQuick.Controls.Universal" ]
}
Depends {
name: "exiv2"
deployment.enabled: product.install
}
/* Then, the actual shared libraries required by libQt5Gui.so,
* libQt5Quick.so and libexiv2.so would be collected
* automatically by QBS if "deployment.enabled" is true on the
* Product.
* Additional properties could be used to exclude some libraries
* from being deployed (because we assume they exist in the
* target system).
*/
deployment.enabled: install
deployment.excludePatterns: [ "libstdc++.so*", "libxcb.so*" ]
/* Excluded libraries could be listed in txt files (the AppImage
* project for example maintains such a list).
*/
// deployment.excludeFiles: [
// "appimage_exclude.txt",
// "macos_excludelist.txt"
// ]
}
}
Does the above look reasonable (and feasible)?
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
Re: [Qbs] Deployment and dependency bundling
On 28/11/19 23:08, Alberto Mardegan wrote: > Whether one prepares macOS bundles, AppImage files of MSI installers, > one has to go through the dependency collection step, which is largely > similar for all platforms. To be more explicit, I'm referring to the > kind of job that on macOS is performed by the macdeployqt tool, and that > seems to be asked in https://bugreports.qt.io/browse/QBS-956. I've been trying to implement a "deployment" module in order to achieve the first step of this process, that is copying all of the application's dependencies into the build directory. However, I'm having some issues with the module's rule. 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". I also tried replacing the `inputs` property with inputs: products.type but this causes QBS to fail with this error: ERROR: Cycle detected in rule dependencies: [deployed_library][application,deployed_library,desktopfile,dynamiclibrary,qm] /home/mardy/src/git/mappero/qbs/modules/deployment/Deployment.qbs:26:18 Or maybe my approach is totally off, and it would be better to implement dependency deployment as a Product (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? Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Deployment and dependency bundling
Hi again :-) Whether one prepares macOS bundles, AppImage files of MSI installers, one has to go through the dependency collection step, which is largely similar for all platforms. To be more explicit, I'm referring to the kind of job that on macOS is performed by the macdeployqt tool, and that seems to be asked in https://bugreports.qt.io/browse/QBS-956. Has some planning work been done in this direction already? My desired outcome would be to have a module which does not create a new product, but rather operates in the same qbs.installRoot directory as my application's product and in an automagical (but configurable) way populates it with the product dependencies, including needed Qt plugins. (For AppImage, that would be followed by an additional step where the qbs.installRoot tree is scanned for libraries and executables, and all of their dependencies (as found by ldd) would be copied over. But this is rather AppImage-specific, so it could live in another module.) Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Module adding source files to a project
Hi Richard, On 28/11/19 01:17, Richard Weickelt wrote: > 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. you know what? I have no idea what I was thinking about when writing my e-mail :-) Indeed, the AppImageKit project provides the appimagetool binary, which is not unreasonable to require to be installed when someone wants to create an AppImage. The appimage QBS module could use a Probe to locate it, or allow the user to specify its location. > 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 ? My biggest concern was with the CPU architecture, as I was assuming (I didn't have an internet connection when I was thinking about this) that the AppImageKit project wouldn't make binaries but for x86_64; this is not the case, and binaries exist for all the most popular architectures. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Module adding source files to a project
Hi there! 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. 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? Do we have examples of other modules having similar requirements? Ciao, Alberto [1]: https://github.com/AppImage/AppImageKit/blob/master/src/runtime.c -- http://www.mardy.it - Geek in un lingua international ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Understanding installation rules
On 19/11/19 00:27, Richard Weickelt wrote: [...] > Does it work with the change suggested above? Yes. Wow. Thanks :-) Alberto -- http://www.mardy.it - Geek in un lingua international ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] Understanding installation rules
Hi all!
About a couple of weeks ago I posted a message to this list about a
module I've written to handle freedesktop.org desktop files. I thought
it was working really well, until I noticed the following problem: if I
manually delete the directory tree which I was as installRoot and I run
QBS again, the .desktop file is not copied over.
I paste here the relevant parts of the module (which you can see in its
entirety here: [1]):
===
FileTagger {
patterns: [ "*.desktop" ]
fileTags: [ "desktopfile_source" ]
}
Rule {
inputs: [ "desktopfile_source" ]
outputFileTags: [ "desktopfile", "application" ]
outputArtifacts: [
{
fileTags: [ "desktopfile" ],
filePath: input.fileName
}
]
prepare: {
...take the input .desktop file and add some keys,
then save it as output.filePath...
}
}
Group {
fileTagsFilter: [ "desktopfile" ]
qbs.install: true
qbs.installDir: "share/applications"
}
===
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.
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?
Any ideas of how to debug this?
Ciao,
Alberto
[1]: https://gitlab.com/mardy/mappero/tree/master/qbs/modules/freedesktop
--
http://www.mardy.it - Geek in un lingua international
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] Module for freedesktop.org compliance on Unix
Hi there! I just wrote a QBS module to help handling icons, desktop files and appstream metadata according to the freedesktop.org standards. You can see it here: https://gitlab.com/mardy/mappero/tree/master/qbs/modules/freedesktop (and the Product using it: https://gitlab.com/mardy/mappero/blob/master/src/qt/qt.qbs) I welcome people to try it out on their applications, and so that if at some point we are confident about it, I could submit it to QBS. So, feedback welcome! :-) 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
Re: [QBS] Is that possible to getting qbs to running with NodeJS?
On 10/28/2015 03:04 PM, 罗勇刚(Yonggang Luo) wrote: > The Qt binaries are too big to ship If you want to ship the buildable source code, why do you need to ship Qt binaries as well? Just let people get them from the Qt site. Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ QBS mailing list QBS@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
