Re: dpkg-buildpackage now sets DEB_BUILD_HOST etc for you?

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