+++ Thomas Petazzoni [2012-11-19 15:49 +0100]: > In Buildroot [1], we had support to use an autoconf cache to speed up > the build. This autoconf cache was shared amongst packages, with the > idea that once a package has verified that such or such system feature > was available or not, it would be written in the cache, and subsequent > packages to be built would not have to do those tests again. > > Unfortunately, we ran into several corner cases where some packages > were using the same autoconf variable name for tests that were mostly > the same, but not exactly, leading to the autoconf cache having a nasty > effect on the build of certain packages, if other packages built before > had "poisoned" the cache with somewhat invalid values. Is this the same cache as that specified by CONFIG_SITE? Debian uses this mechanism to supply config variables unavailable when cross-compiling. Almost all the results are wrapped in if [ "$PACKAGE" = "foo" -o "$PACKAGE_NAME" = "foo" ]; to avoid exactly this poisoning/difference between packages issue. But nearly all the time it is not necessary, and means supplying the same variable in many, many places. If you had any data on which variable/packages were problematic, that would help us streamline this system. I noticed whilst looking into this that autoconf can read this from a default location without setting SITE_CONFIG. I would like to expand this to read the file only when cross-compiling, and to read it from a HOST-arch specific location. Thereby generalising the currently debian-specific mechanism. Is that something that would be of interest upstream - or is there a way to achieve this already (because the file is just a script so maybe it could determine the BUILD and HOST arches itself then read the appropriate thing if needed). Are the variables for configured BUILD and HOST arch available at the time this script is read in? I suppose I should just try this. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf