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/<triplet>, 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-security CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2 CXXFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong -Wformat -Werror=format-security FCFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong FFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong GCJFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong LDFLAGS=-Wl,-z,relro OBJCFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong -Wformat -Werror=format-security OBJCXXFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong -Wformat -Werror=format-security Does it make sense to add generic qbs names for all those things? What happens when debian changes to a different set of options? If not, how do we let qbs set what the package asks for (e.g. via cpp.cLanguageVersion) whilst also honouring the required debian build options? we already have cpp.optimization (grr, US spellings!) and cpp.debugInformation and the various cpp.cxxFlags etc. but no hardening options. So I have no real idea how best to do this. Advice welcome. Avoiding $HOME use ------------------ Debian buildds do not have $HOME available, because per-user data should not affect package builds. qbs defaults to storing settings/profiles in $HOME/.config/QtProject/qbs so that simply doesn't work. Using the --settings-dir option to make it use another dir does the trick but is a bit clumsy as it has to be done on every command. If there was an env var to set which would override this, that would be rather neater. Is there such a thing? Might you consider adding it? Crossbuilding ------------- Does QBS support this, or is it intended to support this? I've not tried yet. Setting the right toolchain commands: <triplet>-gcc, <triplet>-binutils, <triplet>-strip, etc is a good start. config ------ I do have some other questions about the initial profile setup, but this mail is long enough already, so lets leave that for now. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
signature.asc
Description: PGP signature
_______________________________________________ Qbs mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qbs
