[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



On Fri, 30 Mar 2012 08:06:56 +0200
Raphael Hertzog <hertzog@debian.org> wrote:

> On Thu, 29 Mar 2012, Wookey wrote:
> > 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. 
> 
> OK but this should ideally be integrated in common layers such as
> CDBS and debhelper.

The bits needed for cross-builds vary on a package-by-package basis,
have little in common between packages and are only discovered when
someone tries to cross-build that particular package. The list of
values needed by a package or the ways in which the package can
discover the values it needs can vary between package versions.

Generally, there are two kinds of values:

0: architecture-specific extensions - values which are directly related
to the specific architecture and change between architectures but which
aren't sufficiently "common" or "general" to be provided as the default
for all packages on that architecture. (Indeed, supplying these
values to packages which do not normally check for them can cause
build failures due to side-effects within the ./configure scripts.)
These values are currently provided by dpkg-cross as package-specific
extensions to the list of common values (like the size of an int or
void pointer, endianness etc.) which were always part of dpkg-cross.
[0] These values are typically picked up by the ./configure script and
need to be provided for cross-builds solely because otherwise that
specific package will try to discover the value by compiling something
for the HOST architecture and then executing it, which is fatal for a
cross-build.

1: package-breakage prevention values - things which can go into
debian/rules or as patches to the upstream code to supply or prevent
attempted detection of architecture-neutral values or conditionals
around parts of the package build which need to be done using the build
compiler instead of the cross compiler. These values or conditionals
are the same whatever the HOST architecture, they just differ between
native builds vs cross builds. i.e. these are perfect to go inside the 
ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) conditional in
debian/rules.

[0] http://packages.debian.org/sid/all/dpkg-cross/filelist 

So in the second case, it is clear that debian/rules can and should
contain these conditionals and values and the only problem with that is
when the code bit rots because it's not the default build of the
package and the maintainer doesn't get to test that version when
something upstream has changed how it works.

The long term aim for the first case would be for -dev packages to
provide files in a /path/cross.d/$arch/ directory which are generated
during the build of the package for that architecture and which declare
the values which that package had to discover by executing a compiled
test binary. That could be automated, possibly as a "filter" on the full
list of values logged by ./configure. There is a role here for a
debhelper tool.

Both of these changes would be much easier to design, implement, test
and maintain once we have the combination of MultiArch -dev packages and
cross-compilers built by Debian. (Then we could even look at a
cross-piuparts infrastructure to report issues with these mechanisms.)

> > 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. 
> 
> Honestly I have never seen anyone doing cross-builds and calling
> debian/rules manually.

... only because it *always* fails ....

I have longed for such support myself at times. It is incredibly
frustrating to see a cross-build fail 90% of the way through and then
be faced within having to run the clean target after putting in a test
fix to an .install file or similar...

Yes, once all the fixes are in, the actual build is done with
dpkg-buildpackage. In the meantime, we do need support to be able to
run individual debian/rules targets within the cross-build environment
and without having to delete everything you've just cross-compiled.

> So while I believe that cross-build should
> not make different assumptions from native builds (i.e. we want to
> converge), I would also not bother testing this explicitly.
> 
> "dpkg-buildpackage -a" is what people are using (and should be using).

For build runs / packages for upload, yes - absolutely. 

For actual development and testing, no.

Just as the buildd infrastructure must rely on dpkg-buildpackage but
maintainers need to be able to run debian/rules targets manually
sometimes. For exactly the same reasons, cross-build maintainers also
need to be able to run specific debian/rules targets sometimes too.
Except we can't and that should be fixable and should be supportable -
there is no need for a divergence here.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Attachment: pgpdFCNap891w.pgp
Description: PGP signature


Reply to: