autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: autoconf 2.50 tests and cache


From: Pavel Roskin
Subject: Re: autoconf 2.50 tests and cache
Date: Thu, 31 May 2001 08:33:59 -0400 (EDT)

Hello, Akim!

> | I use a single cache file for all packages I configure (by setting
> | cache_file).  When doing the tests ("make check" IIRC) for autoconf 2.50, it
> | seems to pollute this cache file.  Specifically, it seems to be happening
> | around compile.at:154, where it sets CPP to "./mycpp".  This value is then
> | stored in the cache file, and then all further tests involving CPP fail,
> | because they are (presumably) expecting a real pre-processor.

I'm sorry, but using the common cache for all packages is asking for
trouble. The same variable ac_cv_grep_works can mean that grep understands
'-' as stdin for one package and that grep work with binary files for
another.

> | I have temporarily unset cache_file as a work-around.  All the tests are
> | passing now.
>
> I think that's not a work around, that's the way it should be :)

Exactly. All the tests must be running with the cache and config.site
explicitly and reliably disabled.

> OTOH, we must be sure the cache handling works, which probably means
> building other dedicated tests.

Thank's correct. Again, any external influence should be excluded for
those tests as well.

> Also, I have sometimes considered the possibility of having the test
> suite build its own cache.  The good point is that it would give us a
> means to compare the behavior of two Autoconves on the same
> architecture (just compare the `profile' described by the cache,
> that's what Jim does), and the bad one is that we might have some
> tests which are not run because of a previous test.  Not to mention
> the added risk of having two runs of the test suite behave differently
> because of different states of the cache.

It's a bad idea. Cache files don't hold all data, they only have the data
that is relatively hard to obtain. For more complete data use something
like "set | sort >environment.TEST_NUMBER"

> Maybe the solution is in between: adding a new test which runs all the
> macros, and preserve the cache.

Test for working cache is important, but running all macros would be an
overkill in my opinion.

-- 
Regards,
Pavel Roskin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]