[Qbs] Qbs and debian packaging

[Jake Petroules]

"Qbs requires a 'toolchain setup' phase..."

This is still possible in 1.9 and 1.10, but is effectively no longer *required* as Qbs will detect all that information automatically. I'd rewrite that section or otherwise just remove it entirely since you already talk about profiles. I will probably aim to remove setup-toolchains entirely after a few more things get done.

However, setup-qt is still necessary when using Qt, for the time being.

> On Dec 20, 2017, at 8:35 PM, Wookey <wookey at wookware.org> wrote:
> 
> On 2017-12-20 11:09 +0100, Christian Kandeler wrote:
>> On Wed, 20 Dec 2017 04:54:44 +0000
>> Wookey <wookey at wookware.org> 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/
> 
> <fx: fiddling and peering>
> 
> 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
> <fx: more fiddling> 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 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.
> 
> A debian qbs module could presumably do the necesary munging.
> 
> The dpkg-buildflags interface is quite flexible and can select items
> by 'area' (reproducible, hardening, qa, sanitize) and
> vendor/system/user/env and understands prepending and appending and
> setting and removing, but currently output formats are shell, cmdline
> and make, so a new one for qbs would be needed for painless support,
> and teaching it that defines might be wanted without the -D, or linker
> options without the -Wl would be new.
> 
> I'll discuss this with the dpkg maintainers.
> 
> So, I think I have made everything work (except DEB_BUILD_OPTIONS -
> I'll try that tomorrow), but only for the static case. And there are a
> few clarifications requested above. Then I can update the wiki.
> 
> Wookey
> -- 
> Principal hats:  Linaro, Debian, Wookware, ARM
> http://wookware.org/
> _______________________________________________
> Qbs mailing list
> Qbs at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qbs

-- 
Jake Petroules - jake.petroules at qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io