On Wed, 2008-07-30 at 14:46 +0100, Neil Williams wrote: > I'm beginning to wonder about these cache file results - the cache > values that do differ between architectures are already cached in > dpkg-cross because they are truly architecture-dependent. The cache > values that are calculated in the actual builds we need are more > *distribution* dependent - or possibly libc / kernel dependent in some > cases (i.e. linux vs hurd vs bsd not versions of the same kernel). Most > of the tests are for libraries and configuration options that are set > within Debian. > > As such, it is possible that I may be able to collate the test results > into emdebian-tools and generate a file in /etc/ that stores the values > as retrieved from Debian, a linux kernel and glibc. The values could > then be checked by emdebian-tools and the file updated if any of the > values change - insuring us against stale cache values. A specially > crafted configure.ac could be used to generate the file, adding a > dependency on autoconf to emdebian-tools but that is not a problem due > to the existing dependency on build-essential, automake and gcc. The > test could be run by emsetup (which is called each time an empdebuild > chroot is updated). Actually, generating these results is not trivial - the m4 macros are often in the packages themselves, not in autoconf. Copying the m4 files is no better than copying the shell scripting or just the results themselves. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part