[Build-common-hackers] Bug#841761: Bug#841761: cdbs: improve cross compilation with makefile and cmake classes

[Jonas Smedegaard]

Thanks for this - and for nudging me on irc about it :-)

Quoting Helmut Grohne (2016-10-23 11:58:57)
> In 1/class/cmake.mk, the DEB_BUILDDIR variable uses 
> DEB_BUILD_GNU_TYPE. That sounds wrong as building things for the build 
> architecture is not a common thing to do. I suggest to change this to 
> DEB_HOST_GNU_TYPE and note that in the vast majority of uses, this is 
> only an aesthetic change.

Applied.


> When using cmake for cross compilation, one needs to pass a number of 
> variables such as CMAKE_SYSTEM_NAME or CMAKE_SYSTEM_PROCESSOR. I think 
> that cdbs is the right place to add them (as did debhelper) and 
> propose adding a new variables DEB_CMAKE_CROSS_ARGS to 
> 1/class/cmake.mk to hold these.

Applied - after adapting to late expansion (avoiding ifdef/ifndef) to 
ease inclusion of the cdbs snippet (i.e. support inclusion in any order 
and declaring custom variables either before or after inclusions).


> The cmake class defaults to passing $(CC) as CMAKE_C_COMPILER. 
> Unfortunately, CC defaults to cc and cdbs does nothing to fix that. I 
> propose that 1/class/langcore.mk changes CC and CXX such that if they 
> are still at their default values, it will go and substitute 
> triplet-prefixed versions. Note that for doing so, it should in 
> principle include 1/rules/buildvars.mk which sets up DEB_HOST_GNU_TYPE 
> (not done in patch). I wasn't sure whether that is ok, and didn't add 
> it in my patch. If it is, add the include and drop the "ifneq 
> ($(DEB_HOST_GNU_TYPE),)".

I added what I believe is in same spirit but less intrusive: Set to 
host-specific binaries only when cross-compiling, else use the 
Debian-default gcc/g++ names.

Also, adapted to late expansion and use ?= (not :=) (see above).


> When using the makefile class, it only sets up CC for cross 
> compilation, but CXX (and PKG_CONFIG) is often needed as well. It also 
> doesn't honour a user preference for CC.

Applied.


> I note that debhelper's makefile buildsystem doesn't pass CC and 
> friends via environment but via the make command line, because many 
> Makefiles set broken defaults (not covered in patch).

As I recall, such change was avoided for cdbs due to concerns of 
breakage.

I won't take the time to test-compile everything CDBS-based, but if 
someone else will do that, or will take responibility for a simpler 
approach of e.g. just posting a warning to d-devel@ to watch out for 
imploding packages, then I'd be happy to make the change.


> I also note that 1/rules/buildvars.mk wonders when to stop setting 
> DEB_{BUILD,HOST}_* variables. The correct answer is never, because we 
> do not mandate the use of dpkg-buildpackage. Building a package should 
> remain possible by invoking "./debian/rules binary".

Thanks for clarifying. Note dropped.


> It would be far better to just include /usr/share/dpkg/architecture.mk 
> though (not covered in patch).

Odd: I am sure I looked into this in the past but found that that file 
used := instead of ?= but apparently I have been dreaming.  Applied.


I wonder if then also safe to include /usr/share/dpkg/buildflags.mk in 
langcore.mk - I would appreciate your sharp eyes on that, as my messing 
with that has caused problems in the past.


> Most of the issues listed above are addressed in the attached patch. 
> Aspects messing with includes aren't. Please consider it as a basis 
> for discussing cross improvements for cdbs and taking the parts that 
> look like immediate improvements.

Thanks a lot.  If you have more similar suggestions please bring them.

Changes pushed to git.debian.org:/git/build-common/cdbs but not yet 
released, in case you might want to have a look and comment first.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/build-common-hackers/attachments/20170627/78408fd9/attachment.sig>