Re: dpkg-buildpackage now sets DEB_BUILD_HOST etc for you?
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.
But you should not rely on this because calling debian/rules directly
must be supported.
dpkg-buildpackage(1) clearly states:
| Even if dpkg-buildpackage exports some variables, debian/rules should
| not rely on their presence and should instead use the respective
| interface to retrieve the needed values.
And this interface is "dpkg-architecture" itself in this case.
> 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).
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).
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
Reply to: