On Mon, 2008-02-11 at 12:45 -0800, Russ Allbery wrote: > Neil Williams <[EMAIL PROTECTED]> writes: > > > This patch is necessary to allow krb5 to cross-build in Debian, > > following recommendations in autotools-dev. The cache file is handled > > externally. > > What are the bits for using the cache file intended for? I've not seen > that before (and have many other packages using autoconf that don't have > that code).
I'm looking at a better solution for this situation overall, but for this specific package, the cache file for ARM is: krb5_cv_attr_constructor_destructor=yes,yes ac_cv_func_regcomp=yes ac_cv_printf_positional=yes ac_cv_file__etc_environment=no ac_cv_file__etc_TIMEZONE=no When cross compiling, these values cannot be determined by ./configure because it would mean attempting to execute a cross-compiled test binary, created by ./configure itself via the m4 macros. Instead, I trawl through ./configure itself to find the value then trawl through the buildd log for this package at this version on the architecture in question (i.e. the native log) and set the value in the cache file. The final step is to hold the cache file in Emdebian SVN and protect it from clobbering during the build by setting it chmod 444 until the build completes. Generating the cache file is a labour intensive process of trial and error that has so far resisted all attempts at automation. The one good thing is that the build fails at the ./configure stage instead of much later but then sometimes packages use multiple runs of ./configure with different tests at each stage so it can get to be a PITA. Cache files also act as blockers when trying to crossbuild for an architecture that has not yet built the native package. A certain amount of educated guess work can be involved. ;-) This only happens for a few specific tests. In most cases, dpkg-cross provides a "config-site" of cache values which ./configure loads by default upon getting a --host value that does not match --build (dictated by an environment variable set when cross-building). ../krb5_1.6.dfsg.3~beta1-2em1_arm.build contains: ... --mandir=/usr/share/man --without-tcl --build x86_64-linux-gnu --host arm-linux-gnu --cache-file=arm-linux-gnu.cache configure: loading site script /etc/dpkg-cross/cross-config.arm configure: loading cache arm-linux-gnu.cache checking for arm-linux-gnu-gcc... arm-linux-gnu-gcc ... If these values stay stable and/or are discovered across other packages, they could be migrated into the config_site layout. The actual values (and in some cases the variables themselves) will vary by --host architecture, hence the cache file is called $(DEB_HOST_GNU_TYPE).cache Building Emdebian for mips or anything except ARM will therefore require creating suitable cache files but I'm betting that the packages that need cache files for ARM will also need them for any other cross build (and an empty cache file does no harm anyway). Without the cache value, the build simply halts. I'm open to ideas on how this can be done in a more sane manner. ;-) I like autotools and I've read the docs over and over but --cache-file is one of those areas that just doesn't seem to have been "bolted on". http://www.emdebian.org/emdebian/intro.html#cachefiles http://wiki.debian.org/EmdebianGuide#head-ff8d16684c5cf091657b96455b2b8fed6535bdb6 http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_node/autoconf_86.html Currently, I make no attempts to use cache files as shell scripts by defining functions etc. - I simply use them to set particular values. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
