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
signature.asc
Description: signature
