"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 <[email protected]> wrote: > > On 2017-12-20 11:09 +0100, Christian Kandeler wrote: >> On Wed, 20 Dec 2017 04:54:44 +0000 >> Wookey <[email protected]> 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/qbs -- Jake Petroules - [email protected] The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io _______________________________________________ Qbs mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qbs
