On Fri, 30 Mar 2012 08:06:56 +0200 Raphael Hertzog <hert...@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/
pgpmHSSJW2NlX.pgp
Description: PGP signature
