On Fri, 11 Feb 2005, Stepan Kasal wrote:
> Hi Paul.
>
> On Thu, Feb 10, 2005 at 09:25:07AM -0800, Paul Eggert wrote:
> > Why not implement this stuff using "make" rather than "sh"?
> > "make" is designed for dependency handling; the shell isn't.
> >
> > (If that's too drastic for you, I suppose we could reimplement "make"
> > in the shell. :-)
>
> 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?
> I can imagine a good solution though:
> as soon as our empiric resarch proves the hypothesis that /bin/sh has
> functions, we can create a corresponding function for each AC_DEFUNd macro,
> declare these functions near the beginning of the file, and use a shell
> variable to witness whether the function was run or not.
> Then AC_REQUIRE would simply look at the variable and run the function
> if it is not set yet.
> Actually, we don't have to wait until the hypothesis is proven, we can
> implement it immediately, controllable by an option to autoconf.
I actually thought of exactly this solution just the other day.
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.) I
didn't mention it earlier because I thought it was too avant garde.
> But it might be much more work than my proposals,
Actually, I think it's not all that much (especially since I think
it can be done incrementally; not all AC macros need be converted at
once.) since It basically consists of making AC_CACHE_VAL do something
like AS_REQUIRE in that it drops the cache-setting code at the top of the
script and expands only to the function call (and test for previous a
previous call, perhaps) at the place of the macro call. This would
achieve the necessary behavior of having the IF-FOUND and IF-NOT-FOUND
args of the calling macro be expanded regardless of whether the function
has already been called to set the cache.
I think at that point, AC_REQUIRE would insert calls to required
macros in the function bodies. Since the inserted macro call would just
insert a function call and demand the corresponding function definition,
we get for free proper behavior in shell conditionals. There is the
complication that most calls to AC_REQUIRE aren't in their corresponing
AC_CACHE_VALs. I would guess that this could be worked around by looking
inside of the macro expansion stack that's maintained by AC_DEFUN's
prologues and epilogues.
I like this solution because it gives you two significant benefits
(without introducing the use of `make' or any other major quasi-portable
tool): (1) AC macros can safely occur in shell conditional blocks. (3) the
vast majority of cache-setting code that is currently duplicated at every
spot that the cache _might_ be set now is compacted into a single
location.
There is a third proto-benefit. One of the things that has always
bothered me about Autoconf is the ability of cache values to depend on the
arguments used to set them:
# 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.
-Dan
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
