[Qbs] Qbs and debian packaging

[Christian Kandeler]

On Wed, 20 Dec 2017 13:02:22 +0000
Wookey <wookey at wookware.org> wrote:

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

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. Also, "cpp.installNamePrefix: qbs.installRoot" looks very suspicious.

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

In a correctly written project, nothing will ever refer to qbs.installRoot in a way that this value ends up permanently in some binary. However, it is conceivable that there is, for instance, some sort of packaging rule that picks up artifacts from there. In short, the value that qbs thinks the install root is during the build should be the one used when installing, if only for conceptual correctness.

> 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

It is. There is not much support for other languages at the moment, but modules for those can easily be added when there's interest.

> Thanks for reading the page and making comprehensive comments. 

Thanks for writing it ;)

> > > 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)  
> > 
> > I would have thought that this sort of package-specific configuration was the job of the debian rules file. Am I wrong?  
> 
> That's a somewhat philosophical question. Ultimately, yes, all such
> details are for the packaging to get right, but it's good if the
> upstream build does as much as reasonable 'right'. To what degree does
> a user expect to get a 'bare upstream' build, or one built for the
> OS/distro that they are running on?
> I'm not quite sure what the QBS philosophy is here. 

Admittedly I have personally not spent much time thinking about this, but my gut feeling would rather be not to be distribution-aware. We'd have to keep up with their (possibly changing) conventions, for one.

> On rpaths QBS presumably needs to make heavy use for its 'local
> install' mechanism to work, so wants to default them on.

Right. But they can be easily disabled using cpp.useRPaths.

> > > 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.  
> > 
> > There is nothing special about crossbuilding. Historically, the target architecture has been determined by the setup-toolchain command, but recently qbs has shifted more and more to being self-contained in this regard. Setting cpp.toolchainInstallPath, cpp.toolchainPrefix and qbs.sysroot should generally be enough.  
> 
> I agree there is nothing very special about crossbuilding, but build
> systems (especially new ones) regularly make assumptions that make it
> difficult to have it working right :-)

I'm surprised to hear that. One would think that the "host == target" assumption would long be gone. In fact, for qbs, in a way that is the special case, rather than the other way around.


Christian