Re: AC_REQUIRE problems

[Stepan Kasal]

Hi Dan,

On Fri, Feb 11, 2005 at 11:28:17AM -0500, Dan Manthey wrote:
> On Fri, 11 Feb 2005, Stepan Kasal wrote:
> > Sure, I like declarative languages.  It might be even easier to use
> > then the macro language we use now.
> > [comments on make]
>       Okay, was I the only one who thought the suggestion of using
> `make' was a joke?

sure it was joke.  I mean it doesn't seem probable that this idea will
really materialize.
OTOH, it's not that bad for a brainstorming excercise.
Paul will tell us whether my imterpretation is correct.

A bit later, you said:
> I didn't mention it earlier because I thought it was too avant garde.

... well, Paul has mentioned even the avant garde idea of using make.

> It of course requires that function either be portable or fakable.  (I
> salivate at the idea of abusing sh into behaving as if it had functions
> when it doesn't.  I can see some sort of self-sourcing going on.)

Self-sourcing?  Like the `.' builtin?  Or eval?
I'm afraid the former would be slow and the later would be difficult to
use correctly and portably.

I imagined that we could emulate GOSUB by an $ac_call_stack variable and
set of labels.  Unfortunately, it seems that sh doesn't have goto.  :-(
We could use one big case where the patterns would be the subroutine
names...

OK, back to reality: let's just suppose functions for this work.

You mentioned AC_CACHE_VAL and AC_REQUIRE.  Yes, I agree their
implementations would become very similar:
1) emit a function to a ``functions'' diversion
2) the function would check whther certain variable is set, and return
immediately if it is
3) the actual expansion would be only one function call

>       # code from somewhere the user doesn't know about:
>       AC_CHECK_FUNC(foo,...,...,#include <foo.h>)
>       # ac_cv_func_foo now says yes, because foo.h declared foo().
> 
>       # code written by user:
>         AC_CHECK_FUNC(foo,
>       [# user uses bar.h to declare foo(), which doesn't work.],
>         [],#include <bar.h>)
> 
> I can imagine (wish for?) the ability to store some information about the
> set of arguments used to call the function that implements AC_CHECK_FUNC.

The caching mechanism could be fixed to take arguments into account:

1) Either m4 would take the argument list of the macro (AC_CHECK_FUNC in
this case), and use a hash table to compute unique id for it,

2) or we could take the values of shell variables into account and
compute a hash at runtime.  The hash value might be very simple, so that
the ``computattion'' can be performed by sed.  We don't need a number,
we need a string which can be used as a shell variable name.
Collisions can also be solved by a very simple mechanism:
For each cache variable ac_cv_HASH, we would also have ac_cv_HASH_str,
which would contain the string; we could use something like ac_cv_HASH_1
if a collision appeared, etc.

Yes, you are right, we need a shell function to hold this algorithm, it's
too complicated to inline it at each AC_CACHE_* call.

It's really inspiring to discuss with you, Dan.

Stepan