Re: [Qbs] Using QBS with an nonexistent $HOME
On 2020-02-29 09:05 +0300, Alberto Mardegan wrote: > 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. 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. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
[Qbs] qmath3d build issue
I maintain a couple of debian packages that build with qbs. Last night, whilst fixing a couple of bugs in qmath3d (https://tracker.debian.org/pkg/qmath3d) I found a problem: it used to build but no longer does. Well it builds fine but the qbs install step is installing to: $(CURDIR)/debian/tmp/usr/local/usr/lib// instead of $(CURDIR)/debian/tmp/usr/lib// when given: qbs install --settings-dir debian --no-build \ --install-root $(CURDIR)/debian/tmp \ project.libDir:lib/$(DEB_HOST_MULTIARCH) \ profile:deb \ config:qbs-build If I also configure with: qbs config --settings-dir debian profiles.deb.qbs.installPrefix usr/ then it installs into $(CURDIR)/debian/tmp/usr/usr/lib// (so we got rid of the 'local', but still have two 'usr's) To make it work I now have to do: qbs config --settings-dir debian profiles.deb.qbs.installPrefix "" All this doesn't seem to fit with InstallPrefix and InstallRoot info on https://doc.qt.io/qbs/qml-qbsmodules-qbs.html#installation-properties I'm not sure what's going on, and why it has changed. installing to /usr/local/usr/lib/ seems almost always likely to be wrong. I have made it work, but it used to be that the path was correctly constructed from but that seems no longer to be true, and now I don't understand what it is doing. I'm on qbs 1.13.1, and I guess it was 1.11 or 1.12 last time I tried any of this. Is this a deliberate change in behaviour, in which case can someone explain the new logic, or is it a bug? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] debian patches
On 2018-12-21 09:18 +, Christian Kandeler wrote: > By the way, I was looking at the patches Debian applies, and I have a couple > of questions/comments. > - remove_rpaths.diff: Why is the line that *conditionally* sets the rpath > removed instead of building with the CONFIG value that exists for this very > purpose? Is that against some platform convention? Because every package would have to explicitly disable rpaths, when the default in debian is 'turn those pesky rpaths OFF'. It is indeed against debian policy for a build tool to turn them on by default. > - qml_type_descriptions.diff: Will not be needed anymore in qbs 1.13. OK. cool. Will this be obvious to the maintainer because the same patch is adopted upstream? > - processlauncher_destdir.diff: I don't understand this one. Why set > QBS_LIBEXEC_DIR from the outside and then override it? I'm not sure either. cc:ing the author for a clarification. I think this bug may be related/relevant? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869909 Looks like it's dealing with debian's multiarch library layout. It is possible that there is a cleaner fix. > - kfreebsd_soname.diff: Can probably be upstreamed if macOS is also excluded. great. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] --more-verbose causes segfault
On 2018-12-21 16:08 +, Christian Kandeler wrote:
> On Fri, 21 Dec 2018 15:31:44 +
> Wookey wrote:
>
> > Thread 3 "QThread" received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 0x7fff72e89700 (LWP 16286)]
> > 0x778ca457 in QStringRef::toString() const () from
> > /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> >
> > gdb qbs
> > (gdb) run build --settings-dir /tmp --log-level debug --command-echo-mode
> > command-line --no-install profile:deb
> > modules.qbs.installRoot:/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0/debian/tmp
> > project.libDir:lib/x86_64-linux-gnu config:qbs-build
> > (gdb) bt
> > #0 0x778ca457 in QStringRef::toString() const ()
> >from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> > #1 0x77e659e7 in
> > qbs::Internal::ModuleLoader::adjustDefiningItemsInGroupModuleInstances (
> > this=, module=..., dependentModules=std::vector of
> > length 1, capacity 1 = {...})
> > at language/value.h:124
> > #2 0x77e6cfab in
> > qbs::Internal::ModuleLoader::propagateModulesFromParent (
> > this=0x7fff72e88590, productContext=0x7fff6c070850,
> > groupItem=,
> > reverseDepencencies=...) at language/moduleloader.cpp:2214
>
> Thanks. Can you try applying the attached diff?
>
>
> Christian
> diff --git a/src/lib/corelib/language/moduleloader.cpp
> b/src/lib/corelib/language/moduleloader.cpp
> index 583354c4d..41727f5da 100644
> --- a/src/lib/corelib/language/moduleloader.cpp
> +++ b/src/lib/corelib/language/moduleloader.cpp
> @@ -2341,9 +2341,11 @@ void
> ModuleLoader::adjustDefiningItemsInGroupModuleInstances(const Item::Module
> << ", old defining item was " << v->definingItem()
> << " with scope" << v->definingItem()->scope()
> << ", new defining item is" << replacement
> -<< " with scope" << replacement->scope()
> -<< ", value source code is "
> +<< " with scope" << replacement->scope();
> +if (v->type() == Value::JSSourceValueType) {
> +qCDebug(lcModuleLoader) << "value source code is"
> <<
> std::static_pointer_cast(v)->sourceCode().toString();
> +}
> replacement->setPropertyDeclaration(propName, decl);
> replacement->setProperty(propName, v);
> } else {
Well spotted. That fixes it.
The old log was:
qbs.moduleloader: Resolving Probe at
"/usr/share/qbs/modules/bundle/BundleModule.qbs:46:5"
qbs.moduleloader: Probe disabled; skipping
qbs.moduleloader: reset instance scope of module "Qt.core" in property
"cxxFlags" of module ("cpp")
) = ?
+++ killed by SIGSEGV (core dumped) +++
Now we get:
qbs.moduleloader: Resolving Probe at
"/usr/share/qbs/modules/bundle/BundleModule.qbs:46:5"
qbs.moduleloader: Probe disabled; skipping
qbs.moduleloader: reset instance scope of module "Qt.core" in property
"cxxFlags" of module ("cpp")
qbs.moduleloader: replacing defining item for prototype; module is
cpp0x7fcda08d1840, property is cxxFlags, old defining item was 0x7fcda08d1450
with scope0x7fcda0021270, new defining item is0x7fcda08d1f00 with
scope0x7fcda08d1840
qbs.moduleloader: reset instance scope of module "Qt.core" in property
"cxxLanguageVersion" of module ("cpp")
qbs.moduleloader: replacing defining item for prototype; module is
cpp0x7fcda08d1840, property is cxxLanguageVersion, old defining item was
0x7fcda08d1450 with scope0x7fcda0021270, new defining item is0x7fcda08d1f00
with scope0x7fcda08d1840
qbs.moduleloader: value source code is ""
qbs.moduleloader: reset instance scope of module "Qt.core" in property
"cxxStandardLibrary" of module ("cpp")
qbs.moduleloader: reset instance scope of module "Qt.core" in property
"defines" of module ("cpp")
qbs.moduleloader: replacing defining item for prototype; module is
cpp0x7fcda08d1840, property is defines, old defining item was 0x7fcda08d1450
with scope0x7fcda0021270, new defining item is0x7fcda08d1f00 with
scope0x7fcda08d1840
qbs.moduleloader: reset instance scope of module "Qt.core" in property
"driverFlags" of module ("cpp")
qbs.moduleloader: replacing defining item for prototype; module is
cpp0x7fcda08d1840, property is driverFlags, old defining item was
0x7fcda08d1450 with scope0x7fcda0021270, new defining item is0x7fcda08d1f00
with scope0x7fcda08d1840
qbs.moduleloader: value source code is ""
Thanks for the very prompt fix.
I'll file a bug to get this fixed in the current debian package.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
[Qbs] --more-verbose causes segfault
I just uploaded dewalls 1.0.0+ds1-7 to debian to fix some minor lintian issues: https://lintian.debian.org/full/woo...@debian.org.html#dewalls However I noticed (whilst trying to comply with the new debian policy about making build logs extra-verbose) that adding --more-verbose to the qbs build line makes it segfault (when building in debian unstable, with dpkg-buildpackage). The normal build without this works fine, as before. That seems like a qbs bug. (Even if I've done something wrong it shouldn't segfault) Attached are the build logs for the normal build and the build with the verbose option. Anyone know what's going on? You can get the relevant package from http://deb.debian.org/debian/pool/main/d/dewalls/dewalls_1.0.0+ds1-7.dsc (in a few hours) Or get the current -6 and add --more-verbose to the qbs build line in debian/rules The current build looks like this: qbs build --settings-dir /tmp --command-echo-mode command-line --no-install \ profile:deb \ modules.qbs.installRoot:$(CURDIR)/debian/tmp \ project.libDir:lib/$(DEB_HOST_MULTIARCH) \ config:qbs-build And changing it to: qbs build --settings-dir /tmp --more-verbose --command-echo-mode command-line --no-install \ profile:deb \ modules.qbs.installRoot:$(CURDIR)/debian/tmp \ project.libDir:lib/$(DEB_HOST_MULTIARCH) \ config:qbs-build produces the segfault. See https://sources.debian.org/src/dewalls/1.0.0+ds1-6/debian/rules/ Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ dpkg-buildpackage: info: source package dewalls dpkg-buildpackage: info: source version 1.0.0+ds1-7 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Wookey dpkg-source --before-build . dpkg-buildpackage: info: host architecture amd64 fakeroot debian/rules clean dh clean debian/rules override_dh_clean make[1]: Entering directory '/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0' # tidy up qbs profile builddirs rm -r qbs-build rm debian/libdewalls.pc rm: cannot remove 'debian/libdewalls.pc': No such file or directory make[1]: [debian/rules:62: override_dh_clean] Error 1 (ignored) dh_clean make[1]: Leaving directory '/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0' dpkg-source -b . dpkg-source: info: using source format '3.0 (quilt)' dpkg-source: info: building dewalls using existing ./dewalls_1.0.0+ds1.orig.tar.gz dpkg-source: info: using patch list from debian/patches/series dpkg-source: warning: ignoring deletion of directory lib dpkg-source: warning: newly created empty file 'fixup' will not be represented in diff dpkg-source: info: building dewalls in dewalls_1.0.0+ds1-7.debian.tar.xz dpkg-source: info: building dewalls in dewalls_1.0.0+ds1-7.dsc debian/rules build dh build dh_update_autotools_config dh_autoreconf debian/rules override_dh_auto_configure make[1]: Entering directory '/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0' qbs-setup-toolchains --settings-dir /tmp --detect Trying to detect gcc... Profile 'gcc' created for '/usr/bin/gcc'. Trying to detect clang... clang not found. QT_SELECT=5 qbs-setup-qt --settings-dir /tmp /usr/bin/qmake deb Could not open prl file '/usr/lib/x86_64-linux-gnu/libQt5DeviceDiscoverySupport.prl' for module 'QtDeviceDiscoverySupport' (No such file or directory), and failed to deduce the library file path. This module will likely not be usable by qbs. Could not open prl file '/usr/lib/x86_64-linux-gnu/libQt5EglSupport.prl' for module 'QtEglSupport' (No such file or directory), and failed to deduce the library file path. This module will likely not be usable by qbs. Could not open prl file '/usr/lib/x86_64-linux-gnu/libQt5FontDatabaseSupport.prl' for module 'QtFontDatabaseSupport' (No such file or directory), and failed to deduce the library file path. This module will likely not be usable by qbs. Could not open prl file '/usr/lib/x86_64-linux-gnu/libQt5InputSupport.prl' for module 'QtInputSupport' (No such file or directory), and failed to deduce the library file path. This module will likely not be usable by qbs. Could not open prl file '/usr/lib/x86_64-linux-gnu/libQt5GlxSupport.prl' for module 'QtGlxSupport' (No such file or directory), and failed to deduce the library file path. This module will likely not be usable by qbs. Could not open prl file '/usr/lib/x86_64-linux-gnu/libQt5PlatformCompositorSupport.prl' for module 'QtPlatformCompositorSupport' (No such file or directory), and failed to deduce the library file path. This module will likely not be usable by qbs. Could not open prl file '/usr/lib/x86_64-linux-gnu/libQt5Bootstrap.prl' for module 'QtBootstrap' (No such file or directory), and fa
Re: [Qbs] How to pass -march=armv7-a to the g++ linking command line (without -Wl, )
On 2018-01-16 12:08 +1300, Christian Gagneraud wrote: > > I found this piece of information very interesting indeed, what's your > stance about -march then? In my case, I have one toolchain per platform > (roughly), they all have the same generic triplet (arm-linux-gnueabi), but > target different ARM arch (armv5te, armv6, cortex A?, ...) and actually have > sometimes different float ABI. I think you are doing it wrong, in more than one way :-) I like to distinguish between ISA (instruction set) and ABI (Application Binary Interface). An 'architecture' in Debian is actually an ABI (not a machine, nor a CPU). That never changes for the lifetime of the architecture. The ISA that arch is built with can change over time as newer hardware becomes a sensible default i386-> i486 -> i686 in the i386-linux-gnu ABI, and armv4t -> armv5 -> armv7 in the arm-linux-gnueabi ABI, for example. A platform is a combination of ISA and ABI. It may be able to run more than one ABI, but when you chose an OS it all has to have a matching ABI so that libraries work together. It has a 'natural' ISA it can run, but it can generally run all older ones too (some exceptions, especially with mips). Binary distros pick a base (old, generic) ISA to use that will work everywhere. If you are building everything for yourself then you can optimise for the specific platform. So you should have a toolchain for each ABI, not for each platform. Which ISA you default it to, or set your builds to, depends on what hardware you expect the code to be run on/optimised for. Changing the ISA you build for on a particular build (e.g. to optimise for particular hardware) does not change the ABI so stuff will still link and work together with other libraries. If you get this distinction straight in your head it generally helps with thinking about this stuff (which is quite messy on some architectures, like 32-bit arm and mips). Obvsiouly there are toolchains which can produce output for more than one ABI with the right incantations (-m32 on x86_64-linux-gnu compiler will generate i386-linux-gnu ABI, and -mfloat-abi=hard-float on arm-linux-gnueabi compiler will get you you arm-linux-gnueabihf ABI), but the problem with all these magic options is that they are specific to particular toolchain+ABI tuples and are not consistent between architectures. This makes them a pain for upstreams and build systems and best avoided by just letting the build set HOST= and using that. Obviously there are arch-specific ISA and optimisation settings. Upstreams should try to avoid setting these (they don't know what they will be built for) but you can always set them at build time if you know what you want. Does that all make sense. Are we off-topic for this mailing list yet? > PS: Glad to see you on this ML, I remember you from the Emdebian project > when I gave it a try, that was 10 years ago! ;) Yep - that was me :-) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] How to pass -march=armv7-a to the g++ linking command line (without -Wl, )
On 2018-01-15 15:13 +0100, Ola Røer Thorsen wrote: > I've got a product running on Linux arm imx6. It's being cross-compiled on > Linux x86_64. I've got it set up with both qmake and now qbs that hopefully > should replace qmake at some point. > > The qmake build ends up linking the application with a command line like this: > > arm-fslc-linux-gnueabi-g++ > -mfloat-abi=hard > I'm struggling to find the property or similar in the cpp module that adds the > "-mfloat-abi=hard"-option to g++ when used for linking. It's not just linking, its an ABI option that applies to the compile stage too. ABIs are so fundamental that these are two different architectures in Debian-based distros: armel and armhf. Which have different toolchains, and cross-toolchains, so if you use the right triplet then you get the right output and everything matches up. I would question why you are using a linux-gnueabi toolchain when you want linux-gnueabihf outputs. Obviously it can be done, but a good way to avoid problems with the wrong ABI is to use a toolchain that defaults to the right thing. I don't know what your base distro is, but if it's debian-based then using a the distro-supplied arm-linux-gnueabihf-g++ would avoid this problem completely. If you are in redhat-world I presume there are equivalent cross-toolchains. Keeping ABI info in triplets is much cleaner than special-casing the magic option for getting one ABI whilst building with a toolchain for another, especially in upstream projects. (this includes -m32/-m64 in x86 world, which is also a special case that doesn't necessarily work on other architectures and architecture-pairs). I reaslise this is a rather tangential answer to your actual question, but it is hopefully helpful. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] Qbs and debian packaging
On 2017-12-22 13:15 +0100, Christian Kandeler wrote: > On Fri, 22 Dec 2017 11:01:53 + > Wookey wrote: > > > One other thing that is an issue for debian: > > > > qbs clean doesn't actually clean out all its files; indeed it'll > > create one. It always leaves a $(PWD)/default/default.bg (or whatever > > build-dir name is in use). The debian build notices this new binary > > file added to the source tree and complains. A clean comand is > > supposed to clean out generated files, not generate more :-) > > > > Is there a way to stop this behaviour? > > If it really creates that file, then there was no build directory to begin > with (this is an error from 1.10 on, btw). The .bg file is the build graph > which contains all the meta data about the project, so it cannot be removed. > Compare to "make clean", which does not remove the Makefile either. OK, but an autotools Makefile is shipped with the upstream tarball and thus debian package so leaving one around does not surprise dpkg-source. It does have an odd status in that it is ideally generated as part of the build (from Makefile.in, from Makefile.am), (by autoreconf) but is also shipped. This is due to autotools (frankly unhelpful) model of generating (some of) build file(s) on upstream release, not at build-time. Debian now tries to ignore this and encourages the running of autoreconf at build-time so that 'full' rebuild is done, not just a partial one. I agreee that the Cmake/Qbs model of doing all the build-file generation at build-time makes a lot more sense these days, and is more robust over the long term (e.g as new architectures get added). But it seems to me that it is correct that the build directory would not exist initially, and it would get created at build-time. So making that an error doesn't make much sense to me. Is your model that 'qbs clean' should never be run before 'qbs build' (which would create the directory)? That doesn't fit well with debian packaging, which always starts with the clean target (to try to ensure a clean build, especially when it is not out-of-tree). > I suppose we could add a "distclean" equivalent, e.g.: > $ qbs clean --wipe # simply removes the build dir That would work very well for debian packaging, I think. That's what I'm currently doing 'manually'. > > I am using this command: > > qbs clean --settings-dir /tmp profile:deb qbs-build > > which makes a qbs-build/qbs-build.bg > > ... if you haven't built the project before in that directory. Otherwise, the > file has already existed. > > > and also doesn't actually remove all the files in qbs-build. It > > removes the built binaries and the .o files but not the directories > > they were assembled in. > > If the directories are empty, they should be removed as well. If that does > not happen for you and you can reproduce the behavior with the current > release, please file a bug report. It's not easy for me to test the current release as it not in debian yet. But I'll try to do that. > > I have to do an 'rm -r qbs-build' anyway. Does the qbs clean command > > actually do anything else significant (e.g. in the settings dir) or > > should I just skip it and use 'rm -r qbs-build' ? > > For your purpose, rm is the right tool. qbs clean is more relevant to the > development cycle, where you want to keep the meta data (though it should > hardly ever be needed). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] Qbs and debian packaging
On 2017-12-22 11:01 +, Wookey wrote: > On 2017-12-21 09:40 +0100, Christian Kandeler wrote: > And finally, running tests. > > currently my test-case has a product for the library and a > 'dewalls-test' product for the test binary. But > > qbs run --settings-dir /tmp --no-build -p dewalls-test \ >modules.qbs.installRoot:$(PWD)/debian/tmp \ >project.libDir:lib/$(DEB_HOST_MULTIARCH) \ >profile:deb qbs-build > > only works if the package is actually installed on the build system, > otherwise the library is not found: > > qbs run --settings-dir /tmp --no-build -p dewalls-test \ > > modules.qbs.installRoot:/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0/debian/tmp > \ >project.libDir:lib/x86_64-linux-gnu \ >profile:deb qbs-build > Restoring build graph from disk > Installing > Starting target > '/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0/qbs-build/dewalls-test.deb.384b8e5c/dewalls-test'. > /home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0/qbs-build/dewalls-test.deb.384b8e5c/dewalls-test: > error while loading shared libraries: libdewalls.so.1: cannot open shared > object file: No such file or directory > debian/rules:36: recipe for target 'override_dh_auto_build' failed It turns out that an rpath is being put in, but it is the final system rpath: /usr/lib/x86_64-linux-gnu/ which would be good if we were installing this binary as aprt of the package, but we are not - it's just a test binary to be run at build-time. So I fixed this by explicitly setting the rpath: cpp.rpaths: ["qbs-build/install-root/usr/lib/x86_64-linux-gnu/"] (because 'qbs run' is run with $PWD in the source dir and that's where rpaths have to be relative to). A better version is: cpp.rpaths: ["qbs-build/install-root/" + qbs.installPrefix + project.libDir] but that still has the build dir in it, which seems ugly, so doing it relative to the binary seems better still: cpp.rpaths: ["$ORIGIN/../install-root/" + qbs.installPrefix + project.libDir] But isn't this exactly what Qbs could be doing for me? I suspect I am doing this wrong, and there is a better way. In the debian build context where we have control of the profile and build-dir in use this does work fine, but seems clunky. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] Qbs and debian packaging
On 2017-12-21 09:40 +0100, Christian Kandeler wrote: > On Thu, 21 Dec 2017 04:35:34 + > Wookey wrote: > > > You suggested > > > qbs build --no-install modules.qbs.installRoot:debian/tmp > > > qbs install --no-build modules.qbs.installRoot:debian/tmp > > However this breaks the build, because nothing gets installed into > > debian/tmp. > > Works for me. Which version of qbs is this? 1.8.1 > You should pass in an absolute path, by the way, e.g.: > $ qbs build --no-install modules.qbs.installRoot:$PWD/debian/tmp OK. It still fails even with absolute paths. I have just uploaded dewalls 1.0.0+ds1-3 which has my test case in it. Change qbs install --settings-dir /tmp --no-build \ --install-root $(PWD)/debian/tmp \ profile:deb \ project.libDir:lib/$(DEB_HOST_MULTIARCH) \ qbs-build to qbs install --settings-dir /tmp --no-build \ modules.qbs.installRoot:$(PWD)/debian/tmp \ profile:deb \ project.libDir:lib/$(DEB_HOST_MULTIARCH) \ qbs-build and nothing is installed in $(PWD)/debian/tmp > Also note that from qbs 1.9 on, you don't have to repeat any of the > properties on subsequent qbs invocations, as the values are stored in the > build graph. That'll be nice, but still 1.8 in debian unstable. One other thing that is an issue for debian: qbs clean doesn't actually clean out all it's files, indeed it'll create one. It always leaves a $(PWD)/default/default.bg (or whatever build-dir name is in use). The debian build notices this new binary file added to the source tree and complains. A clean comand is supposed to clean out generated files, not generate more :-) Is there a way to stop this behaviour? I am using this command: qbs clean --settings-dir /tmp profile:deb qbs-build which makes a qbs-build/qbs-build.bg and also doesn't actually remove all the files in qbs-build. It removes the built binaries and the .o files but not the directories they were assembled in. I have to do an 'rm -r qbs-build' anyway. Does the qbs clean command actually do anything else significant (e.g. in the settings dir) or should I just skip it and use 'rm -r qbs-build' ? And finally, running tests. A debian build runs build-time tests after building, but before installing the files into the package location. Should I expect 'qbs run' to run a test program that needs a library, after being built, or does it also have to be installed? Qbs knows where it built the library, so it seems that it should be able to find it, I can't put my own LD_PRELOAD in because Qbs has used some magic directory ID to put it in which I don't know. How is this expected to work? currently my test-case has a product for the library and a 'dewalls-test' product for the test binary. But qbs run --settings-dir /tmp --no-build -p dewalls-test \ modules.qbs.installRoot:$(PWD)/debian/tmp \ project.libDir:lib/$(DEB_HOST_MULTIARCH) \ profile:deb qbs-build only works if the package is actually installed on the build system, otherwise the library is not found: qbs run --settings-dir /tmp --no-build -p dewalls-test \ modules.qbs.installRoot:/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0/debian/tmp \ project.libDir:lib/x86_64-linux-gnu \ profile:deb qbs-build Restoring build graph from disk Installing Starting target '/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0/qbs-build/dewalls-test.deb.384b8e5c/dewalls-test'. /home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0/qbs-build/dewalls-test.deb.384b8e5c/dewalls-test: error while loading shared libraries: libdewalls.so.1: cannot open shared object file: No such file or directory debian/rules:36: recipe for target 'override_dh_auto_build' failed I've updated the debian Qbs wiki page, adding some info on the debian multiarch page on making it work with Qbs, and put some info on the various issues into https://bugreports.qt.io/browse/QBS-417 Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] Qbs and debian packaging
On 2017-12-20 11:09 +0100, Christian Kandeler wrote:
> On Wed, 20 Dec 2017 04:54:44 +
> Wookey wrote:
>
> > b) a wiki page on packaging qbs-using packages for debian-style distros:
> > https://wiki.debian.org/QBS
> >
> > Do please tell me what's incorrect on that page
[snip comments]
OK. Page updated, although there will be more when this conversation is
finished.
You suggested
> qbs build --no-install modules.qbs.installRoot:debian/tmp
> qbs install --no-build modules.qbs.installRoot:debian/tmp
However this breaks the build, because nothing gets installed into debian/tmp.
But this works
> qbs build --no-install modules.qbs.installRoot:debian/tmp
> qbs install --no-build --install-root debian/tmp
I had assumed that --install-root and modules.qbs.installRoot were
equivalent, but it seems they are not. Is this expected? The main
difference seems to be that --install-root creates the directory if it
doesn't exist?
> - Regarding the lib paths: I suppose something along the lines of what
> you show there is the correct approach, though I would not necessarily
> expect project authors to provide debian-specific hooks, but rather
> generic ones. For instance:
> Project { // Or in some project-specific module
> property string libDir: "lib"
> // ...
> }
> DynamicLibrary {
> Group {
> fileTagsFilter: ["dynamiclibrary", "dynamiclibrary_symlink"]
> qbs.install: true
> qbs.installDir: project.libDir
> }
> }
> $ qbs build project.libDir:lib/$DEB_HOST_MULTIARCH
OK. this works, and I agree that a generic name is better.
> Note that "usr" should probably not be part of qbs.installDir, but
> rather is a possible value of qbs.installPrefix.
This works if done on the command line:
qbs install modules.qbs.installPrefix:usr/
project.libDir:lib/$DEB_HOST_MULTIARCH
but not if either variable is set in the profile. They are ignored:
qbs config --settings-dir /tmp modules.qbs.installPrefix usr/
Ah, the namespace was wrong, it should be:
qbs config --settings-dir /tmp profiles.default.qbs.installPrefix usr/
but using
qbs config --settings-dir /tmp profiles.default.project.libDir
lib/$(DEB_HOST_MULTIARCH)
does not work because the
property string libDir: "lib"
in the project file overwrites it unless that var is set on the command line.
Right?
I'm confused about the namespacing. It seems to be different for the
build/install commands and the config command:
qbs config profiles.default.cpp.linkerFlags "-z,relro"
qbs build modules.cpp.linkerFlags:"-z,relro"
both set the linker flags in the build. I can see why there is the
"profiles.default" namespace in the config command, but why does one
have 'modules' in and not the other?
qbs config profiles.default.modules.cpp.linkerFlags "-z,relro"
does not change the linkerFlags in the build.
Also I note that '=' in the config vlaue seems to cause a problem:
qbs config profiles.default.cpp.defines "FORTIFY_SOURCE=2"
does not cause -DFORTIFY_SOURCE=2 in the build, it causes -D2
Ah. OK it needs to be suplied as a quoted list:
qbs config profiles.default.cpp.defines '[ "FORTIFY_SOURCE=2" ]'
> > Honouring buildflags
> >
> >
> Why not just pass the flags on the command line or put them in some sort of
> "packaging profile", e.g. via the qbs config command?
So I have done this, and once I worked out namespace and quoting issues it
works.
The only problem is that a lot on string-munging is required to convert:
CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security
CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2
CXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security
LDFLAGS=-Wl,-z,relro
into
qbs config --settings-dir /tmp profiles.default.cpp.debugInformation true
qbs config --settings-dir /tmp profiles.default.cpp.optimization fast
qbs config --settings-dir /tmp profiles.default.cpp.commonCompilerFlags
-Wdate-time
qbs config --settings-dir /tmp profiles.default.cpp.defines '[
"FORTIFY_SOURCE=2" ]'
qbs config --settings-dir /tmp profiles.default.cpp.cFlags '[
"-fstack-protector-strong", "-Wformat", "-Werror=format-security" ]'
qbs config --settings-dir /tmp profiles.default.cpp.cxxFlags '[
"-fstack-protector-strong", "-Wformat" "-Werror=format-security" ]'
qbs config --settings-dir /tmp profiles.default.cpp.linkerFlags "-z,relro"
So I can do this for a static config of current build flags, but some
work would be involved in automating this so that it still worke
Re: [Qbs] Qbs and debian packaging
On 2017-12-20 15:13 +0100, Christian Kandeler wrote: > On Wed, 20 Dec 2017 13:02:22 + > Wookey wrote: > > Thanks. Apparently, the project author is not aware of the convenience > properties in the cpp module; the project file could be much shorter and > easier to read if they had been used. Yes. To be fair I think they were a very early qbs adopter and fewer existed (e.g. cpp.cxxLanguageVersion) The debian patches (in debian/patches) change the dewalls.qbs file to use these. > Also, "cpp.installNamePrefix: qbs.installRoot" looks very suspicious. yes. that is nobbled in the debian patches too. Dewalls upstream is aware of these changes and will update. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] Qbs and debian packaging
On 2017-12-20 11:09 +0100, Christian Kandeler wrote:
> On Wed, 20 Dec 2017 04:54:44 +
> Wookey wrote:
>
> > I have a few things to package for Debian which use QBS.
> >
> > So I've had to work out how to make QBS fit into debian's build
> > concepts and packaging mechanisms. (e.g separate build and install steps)
> >
> > That has gone reasonably well (although some queries about best
> > practice remain), and I have
> > a) a package in debian (which so far as I can tell is the first one using
> > QBS):
> > https://tracker.debian.org/pkg/dewalls
>
> I'm having trouble locating the actual project sources. Can you point me to
> them?
You can view it here:
https://sources.debian.org/src/dewalls/1.0.0+ds1-2/
or download the source here:
http://deb.debian.org/debian/pool/main/d/dewalls/dewalls_1.0.0+ds1-2.dsc
dget will pull all 3 files, or download the tarball and diff manually as well:
http://cdn-fastly.deb.debian.org/debian/pool/main/d/dewalls/dewalls_1.0.0+ds1.orig.tar.gz
http://cdn-fastly.deb.debian.org/debian/pool/main/d/dewalls/dewalls_1.0.0+ds1-2.debian.tar.xz
> Here are my comments on the wiki page.
> - Regarding the separation of build and install steps:
> 1) Even when not installing during the build, the install root should
>still be passed: qbs build --no-install modules.qbs.installRoot:.
Could you elaborate on why? rpaths is the only thing I can think of
that would be affected (if not actually installing) and we don't want
those pointing to temporary install directories.
> 2) I suggest passing the --no-build flag to the install command, for
>extra safety.
> - From (I think) qbs 1.9 on the profile no longer determines the name of the
> build directory. Instead, there is now the concept of a "configuration".
> Until (and including) qbs 1.10, this name is (unfortunately) given as
> a simple context-less parameter, like this:
> $ qbs build default // Same as "qbs build", dir is named "default"
> $ qbs build myConfig // dir is named "myConfig"
> From qbs 1.11 onwards, there will be a more sensible syntax:
> $ qbs build config:myConfig
> - Regarding the setup: As you have noticed, the current approach to
> storing/reading settings does not really consider anything but a
> "normal user". It'd be great if you could create a task at
> bugreports.qt.io and tell us more about your requirements.
Will do.
> - I find this sentence a bit misleading: "qbs is usually used with
> Qt although in principle it could work for other projects." It might
> be statistically true at this point, but the wording seems to imply
> that using it for non-Qt projects is purely a theoretical thing,
> which is really not the case. I'd prefer something like "qbs is often
> used for Qt projects, in which case the path to qmake [...]"
OK. I wasn't quite sure to what degree it is intended to be a
general-purpose build system, especially for languages other than
C/C++/ObjC
Thanks for reading the page and making comprehensive comments.
> - Regarding the lib paths: I suppose something along the lines of what
> you show there is the correct approach, though I would not necessarily
> expect project authors to provide debian-specific hooks, but rather
> generic ones. For instance:
> Project { // Or in some project-specific module
> property string libDir: "lib"
> // ...
> }
> DynamicLibrary {
> Group {
> fileTagsFilter: ["dynamiclibrary", "dynamiclibrary_symlink"]
> qbs.install: true
> qbs.installDir: project.libDir
> }
> }
> $ qbs build project.libDir:lib/$DEB_HOST_MULTIARCH
Good point.
> Note that "usr" should probably not be part of qbs.installDir, but
> rather is a possible value of qbs.installPrefix.
> - Environment variables can be read with Environment.getEnv().
> See https://doc.qt.io/qbs/jsextension-environment.html.
> - Setting cpp.cxxFlags on the command line should work. Note that your
> example has a typo (cxxflags with a lower-case f). If that's how
> you entered it, that would explain why it didn't work (though you
> should have gotten a warning).
>
> > It might be nice to have a debian support module in QBS to make stuff
> > 'just work'.
>
> https://bugreports.qt.io/browse/QBS-417
> You might want to add suggestions there.
>
> > Supporting multiarch
>
> I think I have addressed most of these above. If anything is still unclear,
> does not work or you simply disagree, please tell me.
[Qbs] Qbs and debian packaging
I have a few things to package for Debian which use QBS.
So I've had to work out how to make QBS fit into debian's build
concepts and packaging mechanisms. (e.g separate build and install steps)
That has gone reasonably well (although some queries about best
practice remain), and I have
a) a package in debian (which so far as I can tell is the first one using QBS):
https://tracker.debian.org/pkg/dewalls
b) a wiki page on packaging qbs-using packages for debian-style distros:
https://wiki.debian.org/QBS
Do please tell me what's incorrect on that page (some probably is - I
claim no particular expertise). Or just fix the page.
However there are things I haven't been able to make work, and quite a
few queries about best practice. If QBS becomes widely-used, debian
packaging tools will need to support it, and if we can make that
reasonably painless for both packagers and upstreams, that is
obviously good. I have more packages to do so would like to work out
at least some documentation on that wiki pages with you (upstream).
So the remaining issues are:
1) Properly supporting multiarch paths
2) Honouring dpkg buildflags and DEB_BUILD_OPTIONS
3) Neater way to avoid $HOME usage?
4) Crossbuilding?
It might be nice to have a debian support module in QBS to make stuff
'just work'. But I don't know if this is a good plan. There may be better ways.
So, in detail:
Supporting multiarch
Debian puts libraries in /usr/lib/, not just /usr/lib, and
not /lib64 /lib /libx32 /libilp32 etc. (You can read all about
multiarch here: https://wiki.debian.org/Multiarch, it's quite a big subject)
QBS does not do this by default when a debian build is detected
(pehaps it could?), nor does it seem to have a 'libdir' concept that
would make this an easy override. (It has an installDir which varies
by type of tagged files AIUI).
The correct triplet is made available to builds in
$DEB_HOST_MULTIARCH, but I have not been able to work out how to read
an env var inside the qbs file (is it possible?). Nor have I been able
to pass a variable in, even though this should work.
I should be able to do this:
Project {
name: package
property string debHostMultiarch: ""
Group {
fileTagsFilter: [ "dynamiclibrary", "dynamiclibrary_symlink" ]
qbs.installDir: "/usr/lib/" + debHostMultiarch
qbs.install: true
}
then call 'qbs install' with something like this:
qbs install --settings-dir /tmp --install-root debian/tmp/ profile:default
debHostMultiarch:$(DEB_HOST_MULTIARCH)
but I can't get this to work. Should it? What am I doing wrong? Should
I set it in the profile so it is automatically available?
Currently I have just used the fact that Qt.core.libPath is set to the
right library path, so I can use that, but it's a hack, and only works
for qt-using projects. (i.e. where module qt is loaded)
There is also the issue for upstream to detect that this is a
'debian-style' build and thus should use multiarch paths. There is
provision for detecting the OS, but not the distro. So perhaps it
should be enabled by some kind of flag? cpp.multiarchPaths perhaps?
Although I expect users would prefer it if the build system just DTRT
automagically. (Similarly debian almost never wants rpath set (except
plugins), and does want soVersions and dynamiclibray_symlinks so those
would be good defaults too)
Honouring buildflags
Debian has standard buildflags, e.g. for security settings, like
hardening flags, and default optimisation. It also has a mechanism for
enabling debug builds or disabling checks (e.g. for crossbuilding or
when they are slow), or disabling optimisation. See
https://www.debian.org/doc/debian-policy/#debian-rules-and-deb-build-options
There are various ways to do this in the build process: typically
some env vars are set to be used in the build, but cammands can be run instead:
e.g.: CPPFLAGS:=$(shell dpkg-buildflags --get CPPFLAGS)
https://wiki.debian.org/HardeningWalkthrough gives quite a lot of
examples for different build systems.
I have not managed to make these work as I don't know if there is a
machanism to use env vars in qbs files. Is there? If not, how should
such info be passed in? Would we need to make equivalent qbs strings/lists?
Also I haven't worked out the 'precedence rules' for QBS. i.e if
cpp.cxxFlags is set in the qbs file, and passed in via a qbs command,
does the latter take precedence? Is there a syntax for += (i.e. add
these options to the existing list) ?
qbs tried to avoid this sticky area of setting flags, because they are
toolchain specific, which makes sense, but we need a way of setting a specific
set of things. The current dpkg-buildflags is:
CFLAGS=-g -O2
-fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=.
-fstack-protector-strong -Wformat -Werror=format-securi
