On Sunday 23 March 2008, Neil Williams wrote: > On Sun, 2008-03-23 at 11:14 +0000, David Goodenough wrote: > > In the patches for util-linux, apt, dpkg, gnupg and mktemp there are > > patches build a file called arm-linux-gnu.cache. This file is then > > copied into the build tree. > > It is put in place by emsource when the patches are applied but it is > ignored by any non-arm-linux-gnu build - each arch would need their own > and emsource/emdebuild support this. That is true of most of them, but not for gnupg which complains that the file does not exist. So I presume that something is wrong with the gnupg rules file. Do you want the .build file to look at? > > Native builds ignore it completely so your i386 builds do not need any > cache files, ./configure can run AC_TRY directly because you aren't > using a cross compiler. > > > Now I realise that the patches can not build an architecture specific > > file, we can not substitute into the diff file names. > > One file per arch, one patch per arch. (Until we come up with a better > solution). > > > So would it not be better to create a file called generic.cache, > > Already exists - dpkg-cross already has a generic cache file for each > arch for values that many applications need. Some of the current cache > values may migrate into there but most are entirely specific to that one > package. > > > and then > > when the cp is done to copy it into the build tree to convert it into an > > architecture specific file name:- > > > > cp generic.cache build-deb/$DEB_HOST_GNU_TYPE.cache > > No. The values themselves differ between architectures, that's why we > have .cache files in the first place. The value of having > arm-linux-gnu.cache is that when preparing a build for armel or mipsel, > you have a head start on *which* cache values may be needed. It is then > simply a case of looking up those values in the native Debian build log > and setting them in the new cache file. > > The problem with cache files is that the cache values might actually > change and then we'd be building the wrong setup. A better solution is > needed but a generic cache file is not it. We need improved support in > autotools so that AC_TRY automatically has a replacement when cross > building instead of just dieing which is actually very rude. Overall, I > would like to see cross-building cleanly supported in autotools with > some degree of backwards-compatibility, so that an update in autoconf > would allow many applications to build a ./configure script that does > not simply die when cross building is detected but I suspect it needs > changes to hundreds of m4 files across the internet. :-( OK > > > Also, how does the emsource program know which patches are architecture > > specific, so that it can ignore patches which are not relevant to the > > architecture you are building? > > It doesn't need to - the patch to debian/rules already handles that via > --cache-file=$(DEB_HOST_GNU_TYPE).cache > > i.e. ./configure is passed the architecture-specific cache file but only > if the DEB_HOST_GNU_TYPE differs from DEB_BUILD_GNU_TYPE. In your case, > even that is ignored.
David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
