please correct my ugly hack

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

please correct my ugly hack

Claudio Fontana
Hello,
I am trying to put checks for available programs in a
for loop in a configure.ac script.

My first attempt was:

for NAME in cp du mv rm sh su mkdir rmdir bunzip2
bzip2 compress gunzip gzip tar unzip zip
    do
    AC_PATH_PROG($NAME, $NAME, [no])
    done

This does not work, so I wrote this terrible hack:

for NAME in cp du mv rm sh su mkdir rmdir bunzip2
bzip2 compress gunzip gzip tar unzip zip
    do
    QNAME=$NAME
    AC_PATH_PROG(QNAME, $NAME, [no])
    eval $NAME=$QNAME
    unset ac_cv_path_QNAME
    done

Can someone shed some light on how the thing should be
properly done?

Thanks for any advice

CLaudio

PS: I am not subscribed to the list yet





               
__________________________________
Discover Yahoo!
Use Yahoo! to plan a weekend, have fun online and more. Check it out!
http://discover.yahoo.com/


_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: please correct my ugly hack

Stepan Kasal
Hello Claudio,

On Wed, Jun 01, 2005 at 07:39:58AM -0700, Claudio Fontana wrote:
> for NAME in cp du mv rm sh su mkdir rmdir bunzip2
> bzip2 compress gunzip gzip tar unzip zip
>     do
>     AC_PATH_PROG($NAME, $NAME, [no])
>     done

The problem with is that the AC_*PROG macros expect a literal as
a parameter.

I can see two ways to fix it:

1) Loop on the m4 level.

m4_foreach([MY_Cmd],
[cp,du,mv,rm,sh,su,mkdir,rmdir,bunzip2,bzip2,compress,gunzip,gzip,tar,unzip,zip],
[AC_PATH_PROG([PRG_]MY_Cmd, MY_Cmd, [no])])

2) Patch Autoconf.  Fix autoconf/lib/autoconf/programs.m4 so that it
uses AS_VAR_*
(Similarly as in lib/autoconf/headers.m4.)
Then your original code should work.

This attitude has the advantage that the generated configure will be
smaller.

I think that the patch which would put AS_VAR_* to programs.m4 would
present a useful general improvement.

Paul, would you accept such a patch?


> for NAME in cp du mv rm sh su mkdir rmdir bunzip2
> bzip2 compress gunzip gzip tar unzip zip
>     do
>     QNAME=$NAME
>     AC_PATH_PROG(QNAME, $NAME, [no])
>     eval $NAME=$QNAME
>     unset ac_cv_path_QNAME
>     done

Another topic: this hack has to clear cache.

That's something I noticed before: AC_CHECK_PROG and caching.
I think the caching is almost redundant here:
- The variable itself is a cache, at least during one run of configure.
- Negative results, which don't set the VAR, cannot be cached.

And what you cache?  Looking to all dirs in path.  Yes, there are
situations when visiting all dirs in path is slow.  But such setup slows
down the build, and we shouldn't try _too much_ trickery to repair
this broken setup.

And the caching can cause unwanted surprises; imagine this:

AC_CHECK_PROGS([FOO], [foo fooie])
FOO=
AC_CHECK_PROGS([FOO], [foo1 foo fooie])

If the first call was successful, it's pulled from the cache.
If it wasn't, configure looks for foo1 first.

Another example:

AC_CHECK_PROGS([FOO], [foo fooie])
if test "$special" = yes; then
        FOO=special-foo
else
        FOO=
fi
AC_CHECK_PROGS([FOO], [foo1 foo fooie])

(A sidenote: you might ask why would one write this code.
Perhaps the first AC_CHECK_PROGS was part of a bigger macro
earlier.  And the `if' before the second AC_CHECK_PROGS is there
because we shouldn't put macros inside `if', right.
In any case, this code is not too weird, so it should work.)

If FOO is set to special-foo, then the AC_CHECK_PROGS pulls the
old value from the cache.  But if FOO is set, AC_CHECK_PROGS
shouldn't touch it!

I thought about the problem for some time, and my impression
is that the interaction with cache is not very clear here.

I think the best solution is to drop caching from programs.m4.

Caching was invented mainly for expensive tests which involve
calling a compiler, which can be really slow.
In most environments, _AS_WALK_PATCH is way quicker than gcc.

Paul, will you buy this?

Stepan Kasal


_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: please correct my ugly hack

Paul Eggert
Stepan Kasal <[hidden email]> writes:

> I think that the patch which would put AS_VAR_* to programs.m4 would
> present a useful general improvement.
>
> Paul, would you accept such a patch?

That sounds good to me, yess.

> I think the best solution is to drop caching from programs.m4.

You can also talk me into this, yes.  The less caching the better,
all other things being equal.


_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: please correct my ugly hack

Ralf Corsepius
In reply to this post by Stepan Kasal
On Wed, 2005-06-01 at 18:33 +0200, Stepan Kasal wrote:

> I think the best solution is to drop caching from programs.m4.
Only over my dead body ;-)

> Caching was invented mainly for expensive tests which involve
> calling a compiler, which can be really slow.
No, caching had been invented for faster interaction of several
configure scripts (CONFIG_SUBDIRS) in large source trees.

Ralf




_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: please correct my ugly hack

Dan Manthey
On Wed, 1 Jun 2005, Ralf Corsepius wrote:

> On Wed, 2005-06-01 at 18:33 +0200, Stepan Kasal wrote:
>
> > I think the best solution is to drop caching from programs.m4.
> Only over my dead body ;-)
>
> > Caching was invented mainly for expensive tests which involve
> > calling a compiler, which can be really slow.
> No, caching had been invented for faster interaction of several
> configure scripts (CONFIG_SUBDIRS) in large source trees.

Can't you just `export PROG' in the root configure to pass the found
value to the sub-configures.  Sure, if you call the sub-configures
directly rather than via the root configure, they have to calculate the
program path themselves, but that hardly seems onerous, and Stepan is
certainly right that the cache behavior is weird.

By the way, note that there seems to be some confusion about whether a
PROG variable is "set".  `PROG=' does _not_ unset it.  How does
AC_CHECK_PROG behave when the variable is set to the empty string?

-Dan



_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: please correct my ugly hack

Ralf Corsepius
On Wed, 2005-06-01 at 13:45 -0400, Dan Manthey wrote:

> On Wed, 1 Jun 2005, Ralf Corsepius wrote:
>
> > On Wed, 2005-06-01 at 18:33 +0200, Stepan Kasal wrote:
> >
> > > I think the best solution is to drop caching from programs.m4.
> > Only over my dead body ;-)
> >
> > > Caching was invented mainly for expensive tests which involve
> > > calling a compiler, which can be really slow.
> > No, caching had been invented for faster interaction of several
> > configure scripts (CONFIG_SUBDIRS) in large source trees.
>
> Can't you just `export PROG' in the root configure to pass the found
> value to the sub-configures.
Well, to some extend yes, but no in general:

* We are talking about several dozens of values. This makes applying
environment variables very unhandy.

* Consider cross compilation. In this case you are building several sub-
trees of a source-tree with different settings.

* Environment variables impose side-effects. They are hard to trace and
easy to miss.

Ralf





_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: please correct my ugly hack

Stepan Kasal
In reply to this post by Dan Manthey
Hello Dan,

On Wed, Jun 01, 2005 at 01:45:49PM -0400, Dan Manthey wrote:
> By the way, note that there seems to be some confusion about whether a
> PROG variable is "set".  `PROG=' does _not_ unset it.  How does
> AC_CHECK_PROG behave when the variable is set to the empty string?

it uses    test "x$VAR" = x

Thus the manual should use the term "is nonempty", not "is set".

(One of the reasons for this behaviour is that unset is not portable.)

Another problem of the documentation is that the same pattern is repeated
in the description of each of the macros.  I tried to fix this some time
ago, but then I put it ad acta with a note "this patch has to be repaired".
I attach the old patch, for reference.  If you or anyone else here could
finish it, I'd be grateful.

Have a nice day,
        Stepan Kasal

_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf

autoconf-20041027-check_prog.patch (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: please correct my ugly hack

Stepan Kasal
In reply to this post by Ralf Corsepius
Hi Ralf,

On Wed, Jun 01, 2005 at 07:08:08PM +0200, Ralf Corsepius wrote:
> On Wed, 2005-06-01 at 18:33 +0200, Stepan Kasal wrote:
> > Caching was invented mainly for expensive tests which involve
> > calling a compiler, which can be really slow.
> No, caching had been invented for faster interaction of several
> configure scripts (CONFIG_SUBDIRS) in large source trees.

Oh, I haven't considered/known this.

(But again, only expensive checks should be cached; in most environments,
AC_*PROG is relatively inexpensive.)

> > I think the best solution is to drop caching from programs.m4.
> Only over my dead body ;-)

I still hope to convince you without causing you any hurt.  ;-)

Yes, I agree, caching is good.  
But caching doesn't help, if it is not transparent.

In other words, FOO and ac_cv_prog_FOO are duplicates.  (FOO itself acts as
a caching variable; if it is nonempty, the macro is skipped.)
But users change FOO themselves, without taking ac_cv_prog_FOO into
account and that brings the unwanted suprises.
(BTW, Claudio has told me that he experienced one of the surprises I
mentioned in my answer to his post; so this is a real-life problem.)

If mere ``export FOO'', as proposed by Dan, is not enough, then I have
another idea:

Let's say that ac_cv_prog_FOO is an ``alias'' to FOO.

How to implement it?

It's relatively easy: just before writing the cache, we'd do:
        ac_cv_prog_FOO=$FOO
for each FOO which have been used as the first parameter to an AC_*PROG* macro.
(I said "have been" as the list of these variables has to be created during the
run of configure, if we adapt programs.m4 to use AS_VAR_*, so that non-literal
variable names are allowed.)

And at the beginning, just after the cache file and config.site were read,
we'd do
         FOO=$ac_cv_prog_FOO
for all ac_cv_prog_* variables read from the cache.

I believe this would be a transparently working caching mechanism for AC_PROG
type macros.

The question is: is this worth it?  Is the setup with "slow directories" so
common?  How commonly are CONFIG_SUBDIRS used?  (I admit I haven't any
experience with this feature, yet.)

Ralf, it would be easier, if you could _live_ with programs.m4 without
caching.
Perhaps we could put the above sketch of ``alias variables'' to a comment
near the top of programs.m4.  As soon as real performance problems appear,
we'd implement it.  (I propose this because I still think that the old
caching scheme in programs.m4 is unusable, and should be removed.)

Happy caching,  ;-)
        Stepan


_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

unset variables, was Re: please correct my ugly hack

Dan Manthey
In reply to this post by Stepan Kasal

On Thu, 2 Jun 2005, Stepan Kasal wrote:

> it uses    test "x$VAR" = x
>
> Thus the manual should use the term "is nonempty", not "is set".
>
> (One of the reasons for this behaviour is that unset is not portable.)

It's documented that the builtin `unset' is non-portable, but what about
the use of unset variables vs. empty variables?  Is this distinction
always meaningful?  (Some of the caveats about MS DOS suggest not?)  Also,
I know that ${var:-default} is not portable.  Is ${var-default}?  For that
matter, I know you can set bash to error out on $var for an unset var,
which would require ${var-}.  I'm ignorant:  is this behavior turned off
by AC_INIT (or whatever)?

-Dan

_______________________________________________

Autoconf mailing list

[hidden email]

http://lists.gnu.org/mailman/listinfo/autoconf


_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf

autoconf-20041027-check_prog.patch (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unset variables, was Re: please correct my ugly hack

Paul Eggert
Dan Manthey <[hidden email]> writes:

> It's documented that the builtin `unset' is non-portable, but what about
> the use of unset variables vs. empty variables?  Is this distinction
> always meaningful?

Yes.

> Also, I know that ${var:-default} is not portable.  Is
> ${var-default}?

Yes.

> For that matter, I know you can set bash to error out on $var for an
> unset var

Let's not do that, please.  Let's stick to traditional behavior
blessed by POSIX.  If Bash's behavior is inherited I suppose we should
turn it off.


_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unset variables, was Re: please correct my ugly hack

Stepan Kasal
Hello,

On Thu, Jun 02, 2005 at 11:35:20PM -0700, Paul Eggert wrote:
> > It's documented that the builtin `unset' is non-portable, but what about
> > the use of unset variables vs. empty variables?  Is this distinction
> > always meaningful?
>
> Yes.

let me add that the cache uses the distinction whether the variable is
set or not.   (test "${ac_cv_foo+set}" = set)

> > Also, I know that ${var:-default} is not portable.  Is
> > ${var-default}?
>
> Yes.

And also
        test "${ac_cv_foo+set}" = set
which is used by the caching mechanism.

Have a nice day,
        Stepan


_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: please correct my ugly hack

Stepan Kasal
In reply to this post by Stepan Kasal
Hello again,

I'm sorry that I post a followup to my own mail:

On Thu, Jun 02, 2005 at 09:04:06PM +0200, Stepan Kasal wrote:
> On Wed, Jun 01, 2005 at 07:08:08PM +0200, Ralf Corsepius wrote:
> > No, caching had been invented for faster interaction of several
> > configure scripts (CONFIG_SUBDIRS) in large source trees.

So the subprojects can share the cache, even though their
configure.ac files might differ.

The consequences:

1) I proposed:
> Let's say that ac_cv_prog_FOO is an ``alias'' to FOO.   [...]
> just before writing the cache, we'd do:   ac_cv_prog_FOO=$FOO

This would be incorrect.  The cache would be affected by the skew
which ca be added by each configure script.

2)
Two configure.ac files can contain AC_CHECK_PROGS([DUMP], ...),
with a totally different meanings.
Thus the general macros cannot use cache.
But the checks for particular programs (AC_PROG_AWK, AC_PROG_CC, etc.)
can cache their findings.


There is still one problem:

The variable itself has to have higher priority than its cache shadow.

Currently, AC_PROG_AWK is something like

AC_CACHE_VAL([ac_cv_prog_AWK], [if test "x$AWK" = x; then ... ; fi])

but it should be:

if test "x$AWK" = x; then
        AC_CACHE_VAL([ac_cv_prog_AWK], [...])
fi


A plan:
The current caching scheme in programs.m4 has serious problems and has
to be removed.  That will significantly improve correctness.
(I could get to that approx in July, I guess.)

Then the caching can be added back to the particular checks, if anyone
cares.  (For specific setups, this will increase the speed again.)

Have a nice day,
        Stepan Kasal


_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: please correct my ugly hack

Ralf Corsepius
On Fri, 2005-06-03 at 09:37 +0200, Stepan Kasal wrote:

> Hello again,
>
> I'm sorry that I post a followup to my own mail:
>
> On Thu, Jun 02, 2005 at 09:04:06PM +0200, Stepan Kasal wrote:
> > On Wed, Jun 01, 2005 at 07:08:08PM +0200, Ralf Corsepius wrote:
> > > No, caching had been invented for faster interaction of several
> > > configure scripts (CONFIG_SUBDIRS) in large source trees.
>
> So the subprojects can share the cache,
Exactly.

>  even though their
> configure.ac files might differ.
Right, this is the troublesome spot. Such configure scripts must be
carefully designed to interact properly on caches.

Before autoconf-2.5x, sharing caches had been enabled by default, since
autoconf-2.49 (IIRC) sharing caches has been disabled.

> The consequences:
>
> 1) I proposed:
> > Let's say that ac_cv_prog_FOO is an ``alias'' to FOO.   [...]
> > just before writing the cache, we'd do:   ac_cv_prog_FOO=$FOO
>
> This would be incorrect.  The cache would be affected by the skew
> which ca be added by each configure script.
>
> 2)
> Two configure.ac files can contain AC_CHECK_PROGS([DUMP], ...),
> with a totally different meanings.
This would mean, these configure scripts are not designed to properly
interact.

> Thus the general macros cannot use cache.
Packages need to be designed/prepared for this to work.

> But the checks for particular programs (AC_PROG_AWK, AC_PROG_CC, etc.)
> can cache their findings.
>
>
> There is still one problem:
>
> The variable itself has to have higher priority than its cache shadow.
This is how they are supposed to work. Environment variables are
supposed to override the cache.

> Currently, AC_PROG_AWK is something like
>
> AC_CACHE_VAL([ac_cv_prog_AWK], [if test "x$AWK" = x; then ... ; fi])
>
> but it should be:
>
> if test "x$AWK" = x; then
> AC_CACHE_VAL([ac_cv_prog_AWK], [...])
> fi
Nope.

> A plan:
> The current caching scheme in programs.m4 has serious problems and has
> to be removed.  That will significantly improve correctness.
Which? I don't see them.

Conversely, this scheme is almost as old as autoconf (I don't recall
when they were introduces autoconf-2.8 or something) and many major
packages apply it, so changing anything inside is dangerous.

> (I could get to that approx in July, I guess.)
>
> Then the caching can be added back to the particular checks, if anyone
> cares.  (For specific setups, this will increase the speed again.)
Frankly speaking, I dislike this plan.

Either autoconf should perform a clear cut, that is abandon caches
entirely, which means autoconf will be totally incompatible to any
former version of autoconf (a side-effect will be that autoconf will
have to be versioned), or nothing should change in autoconf's behavior.

Ralf




_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: please correct my ugly hack

Stepan Kasal
Hi,

On Fri, Jun 03, 2005 at 02:34:35PM +0200, Ralf Corsepius wrote:
> > The variable itself has to have higher priority than its cache shadow.
> This is how they are supposed to work. Environment variables are
> supposed to override the cache.

but in case of programs.m4 this is not the case.  Try it:

$ configure -C
...
$ ./configure -C AWK=newawk
...
checking for gawk... (cached) gawk

(I know this is not proper use of cache, and that configure would complain
if AWK was properly declared as precious, but that's not my point now.)

This shows that in case of AC_*PROG* macros, the cache has higher priority
than the variable itself.

This is why I said:
> > Currently, AC_PROG_AWK is something like
> >
> > AC_CACHE_VAL([ac_cv_prog_AWK], [if test "x$AWK" = x; then ... ; fi])
> >
> > but it should be:
> >
> > if test "x$AWK" = x; then
> > AC_CACHE_VAL([ac_cv_prog_AWK], [...])
> > fi

> > A plan:
> > The current caching scheme in programs.m4 has serious problems and has
> > to be removed.  That will significantly improve correctness.
> Which? I don't see them.

The problem described above is one.

Another two are the examples I posted in
http://lists.gnu.org/archive/html/autoconf/2005-06/msg00003.html
the behaviour is counterintuitive.

> Conversely, this scheme is almost as old as autoconf (I don't recall
> when they were introduces autoconf-2.8 or something) [...]

Was the bug I presented above introduced at the beginning?
Or did it happen later?

Please believe me, I don't want to attack the caching mechanism in general.
I just want to remove it from programs.m4, because it doesn't work well
there.

> Either autoconf should perform a clear cut, that is abandon caches
> entirely,
No, I don't want that.
> which means autoconf will be totally incompatible to any
> former version of autoconf

_incompatible_ ?

If I remove caching from AC_CHECK_PROG and AC_CHECK_TOOL, what
_incompatibility_ would it cause?
Would it break some documented behaviour?

Have a nice day,
        Stepan


_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: please correct my ugly hack

Ralf Corsepius
On Fri, 2005-06-03 at 16:09 +0200, Stepan Kasal wrote:

> > Either autoconf should perform a clear cut, that is abandon caches
> > entirely,
> No, I don't want that.
> > which means autoconf will be totally incompatible to any
> > former version of autoconf
>
> _incompatible_ ?
>
> If I remove caching from AC_CHECK_PROG and AC_CHECK_TOOL, what
> _incompatibility_ would it cause?
> Would it break some documented behaviour?
Yes, caching.

There exist packages which rely on sharing caches (some intentionally,
some unintentionally), there exist packages which are rely on preset
caches, and finally here is config.site (which I have never used, and
don't actually know how it interacts with config.cache's)

Ralf





_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unset variables, was Re: please correct my ugly hack

Dan Manthey
In reply to this post by Paul Eggert
On Thu, 2 Jun 2005, Paul Eggert wrote:

> Dan Manthey <[hidden email]> writes:
>
> > For that matter, I know you can set bash to error out on $var for an
> > unset var
>
> Let's not do that, please.  Let's stick to traditional behavior
> blessed by POSIX.  If Bash's behavior is inherited I suppose we should
> turn it off.
>

Oh, I didn't mean to advocate this at all.  I set Bash to have this
behavior when it's my interactive shell, and I somehow managed to run
configure with it, causing configure to fail.  I think had to go through
some rigamarole to do this, so I wouldn't worry about it, but it might be
appropriate to explicitly disable the feature during the cleaning at start
up.  *Shrug.*  Clearly, this isn't a big issue, though.

-Dan


_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: please correct my ugly hack

Bob Friesenhahn
In reply to this post by Ralf Corsepius
On Fri, 3 Jun 2005, Ralf Corsepius wrote:
> Yes, caching.
>
> There exist packages which rely on sharing caches (some intentionally,
> some unintentionally), there exist packages which are rely on preset
> caches, and finally here is config.site (which I have never used, and
> don't actually know how it interacts with config.cache's)

The config.site file is always sourced toward the beginning of the
configure script.  As such, the config.cache influences configure so
that the results are identical to when configure was first executed.
If config.site is changed in the mean time, the the answers may be
different than if config.cache did not exist since (as far as I know)
config.cache is not invalidated if config.site is newer than
config.cache.

Bob
======================================
Bob Friesenhahn
[hidden email], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/


_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: please correct my ugly hack

Stepan Kasal
In reply to this post by Ralf Corsepius
Hello,

On Fri, Jun 03, 2005 at 06:40:49PM +0200, Ralf Corsepius wrote:
> > If I remove caching from AC_CHECK_PROG and AC_CHECK_TOOL, what
> > _incompatibility_ would it cause?
> > Would it break some documented behaviour?
> Yes, caching.

you are right, this is incompatibility.

But I don't think this would be breaking any documented behaviour,
as I cannot find any place which says that AC_CHECK_PROGS caches its
result.  In my quick search, I found only a note that "many checks"
cache their results.

> There exist packages which rely on sharing caches (some intentionally,
> some unintentionally), there exist packages which rely on preset
> caches,

If this is a real-life problem, that I really should add caching to
specific checks (AC_PROG_AWK and such).

If they rely on sharing ac_cv_prog_WEIRD, then I'd say they aren't
properly designed, and they will have to be fixed.

> and finally here is config.site (which I have never used, and
> don't actually know how it interacts with config.cache's)

I think that config site should use something like
: ${AWK=gawk}
and not mess with the ac_cv_prog_AWK.

Have a nice day,
        Stepan


_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: please correct my ugly hack

Ralf Wildenhues
Hi Stepan,

* Stepan Kasal wrote on Sat, Jun 04, 2005 at 09:04:17AM CEST:
> On Fri, Jun 03, 2005 at 06:40:49PM +0200, Ralf Corsepius wrote:
> > > If I remove caching from AC_CHECK_PROG and AC_CHECK_TOOL, what
> > > _incompatibility_ would it cause?
> > > Would it break some documented behaviour?
> > Yes, caching.
>
> you are right, this is incompatibility.

Yes, I agree with Ralf there.

> But I don't think this would be breaking any documented behaviour,
> as I cannot find any place which says that AC_CHECK_PROGS caches its
> result.  In my quick search, I found only a note that "many checks"
> cache their results.

It _is_ documented, albeit a little implicitly.
  info Autoconf 'Cache Variable Names'
mentions, how the cache names are built, and
  info Autoconf 'Macro Names'
mentions the types, for example `PROG' and `PATH'.
Reading that, plus observing that the corresponding cache names _are_
used would make /me/ innocent user believe they were safe to use.

Regards,
Ralf


_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Loading...