[Qbs] Qbs and debian packaging

Christian Kandeler christian.kandeler at qt.io
Thu Dec 21 09:40:36 CET 2017

On Thu, 21 Dec 2017 04:35:34 +0000
Wookey <wookey at wookware.org> 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? You should pass in an absolute path, by the way, e.g.:
$ qbs build --no-install modules.qbs.installRoot:$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.

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

On the command line you can set all kinds of properties:
$ qbs modules.mymodule.property:value
$ qbs products.myproduct.property:value
$ qbs projects.myproject.property:value

Since projects and products, for instance, have their own namespace, there could be ambiguities otherwise:
$ qbs p.property:value // Oops, there is a project named "p" and also a product (or module)!

Profiles, on the other hand, are intended to be used across different projects and can therefore not set project and product properties, so no disambiguation is necessary.

> 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
> <fx: more fiddling> Ah. OK it needs to be suplied as a quoted list:
>   qbs config profiles.default.cpp.defines '[ "FORTIFY_SOURCE=2" ]'

$ qbs config profiles.default.cpp.defines '"FORTIFY_SOURCE=2"'

You just needed double-quoting there for it to to still be a string after shell expansion.
In general, our command-line tools allow full JS syntax as well as simple strings for less verbosity, to simplify the normal case where no special characters are involved. Lists can also be specified in CSV format in that case.

> > 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
> 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 worked when
> the flags changed (they do from time to time, and can be changed
> per-user, per-system etc). We wouldn't want every debian rules file to
> have to have a lot of boilerplate for this conversion.

The pure format conversion could probably easily automated, but the translation from raw compiler option to qbs convenience property is a bit of an issue, I suppose.


More information about the Qbs mailing list