+++ Raphael Hertzog [2012-03-29 21:06 +0200]: > Hi, > > On Thu, 29 Mar 2012, Wookey wrote: > > Anyone know when this happened and what if any, the limitations are? > > It's certainly true in wheezy, squeeze, precise and oineiric. > > This has always been the case ever since dpkg-architecture has been > introduced.
OK, shows how much I know :-) > But you should not rely on this because calling debian/rules directly > must be supported. Hmm, but if a package cannot use the variables set by dpkg-buildpackage and must set them itself, what is the point of dpkg-buildpackage setting them? To save the package exporting the variables? > > Now, you can build packages without using dpkg-buildpackage by calling > > rules directly, and in that case the rules file would need to call > > dpkg-architecture, but someone would have to convince me that that was > > an interface worth supporting for non-native builds, because I > > have certainly always considered the minimal interface for cross > > package-building to be dpkg-buildpackage -a<arch>, and in practice > > there are other things you need to do for non-trivial packages (set > > CONFIG_SITE, set DEB_BUILD_OPTS=nocheck). (and ensure various things > > like toolchain and dpkg-cross are installed). And I don't think we want > > that stuff in every single rules file. > > I don't see why you're differentiating non-native builds from native > builds (unless you assume different debian/rules files). Well, perhaps I shouldn't (and indeed I'd like us to get to a point where we don't), but currently, in practice, non-native builds need other things setting in the environment anyway so even using dpkg-buildpackage isn't necessarily sufficient, whereas for a native build it always is. Although what you're telling me is that that's irrelevant because in fact just calling debian/rules should also always be sufficient. To make that true for cross-builds requires more than we are putting in rules files at the moment. So there is a difference. Now if everyone is happy that debian/rules remains the canonical interface even for cross-builds and that they should work without dpkg-buildpackage help then I should start testing on that basis. I have not done that to date. The obvious bits that will be missing in many packages are something to deal with autoconf cache variables (currently handled by dpkg-cross and setting CONFIG_SITE externally). And something to set cmake toolchain file variables (also currently in dpkg-cross, but I suspect it needs updating for multiarch). > In any case, if you're worried about the boilerplate code required to > get the variables defined, you can now use "include > /usr/share/dpkg/architecture.mk" to avoid it (but this requires > dpkg-dev >= 1.16.1). OK. That's useful to know. And fine from here on in. I'll add that to the page. Keeping boilerplate in includable snippets seems like an excellent plan generally. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120329203052.gu26...@dream.aleph1.co.uk
