Re: Global autoconf cache

2012-11-20 Thread Richard Stallman
Therein lies the problem. How do you identify which tests are standard, Standard tests are those generated by Autoconf macros without customization. You said that sometimes various packages use the same name for different tests. That won't happen with standard test names, because using a st

Re: Global autoconf cache

2012-11-19 Thread Eric Blake
On 11/19/2012 02:32 PM, Richard Stallman wrote: > I personally spent quite a significant amount of time fixing a few > configure.{ac,in} files in various packages, but in the end, we gave up > with this idea and no longer use the autoconf cache. > > If we use the cache for standard tes

Re: Global autoconf cache

2012-11-19 Thread Richard Stallman
I personally spent quite a significant amount of time fixing a few configure.{ac,in} files in various packages, but in the end, we gave up with this idea and no longer use the autoconf cache. If we use the cache for standard tests only, could that fix this problem? -- Dr Richard Stal

Re: Global autoconf cache

2012-11-19 Thread Wookey
+++ 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

Re: Global autoconf cache

2012-11-19 Thread Thomas Petazzoni
Dear Richard Stallman, On Wed, 14 Nov 2012 16:49:58 -0500, Richard Stallman wrote: > The global cache that autoconf formerly used was very good for > efficiency of autoconf, especially when building lots of packages. > Without that, it is slow. > > I am told it had a problem: results depended on

Re: Global autoconf cache

2012-11-14 Thread NightStrike
On Wed, Nov 14, 2012 at 11:49 AM, Richard Stallman wrote: > This problem could be fixed automatically by making the the package > manager communicate with autoconf, to clear the cache whenever certain > packages are installed. Sounds like a fix on the package manager side. Interestingly, this ca

Global autoconf cache

2012-11-14 Thread Richard Stallman
The global cache that autoconf formerly used was very good for efficiency of autoconf, especially when building lots of packages. Without that, it is slow. I am told it had a problem: results depended on things such as compiler options, that varied from package to package, this suggests the idea o