[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AC_REQUIRE problems
From: |
Stepan Kasal |
Subject: |
Re: AC_REQUIRE problems |
Date: |
Sat, 12 Feb 2005 10:20:45 +0100 |
User-agent: |
Mutt/1.4.1i |
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
- AC_REQUIRE problems, Stepan Kasal, 2005/02/09
- Re: AC_REQUIRE problems, Dan Manthey, 2005/02/09
- Re: AC_REQUIRE problems, Paul Eggert, 2005/02/10
- Re: AC_REQUIRE problems, Stepan Kasal, 2005/02/11
- Re: AC_REQUIRE problems, Dan Manthey, 2005/02/11
- Re: AC_REQUIRE problems,
Stepan Kasal <=
- Re: AC_REQUIRE problems, Dan Manthey, 2005/02/24
- Re: AC_REQUIRE problems, Paul Eggert, 2005/02/24
- Re: AC_REQUIRE problems, Stepan Kasal, 2005/02/25
- Re: AC_REQUIRE problems, Paul Eggert, 2005/02/13
- Re: AC_REQUIRE problems, Stepan Kasal, 2005/02/14
- Re: AC_REQUIRE problems, Paul Eggert, 2005/02/14
- Re: AC_REQUIRE problems, Stepan Kasal, 2005/02/15
- Re: AC_REQUIRE problems, Gregorio Guidi, 2005/02/15
- Re: AC_REQUIRE problems, Stepan Kasal, 2005/02/15
- Re: AC_REQUIRE problems, Dan Manthey, 2005/02/15