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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
