automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

My current work and a silly idea


From: akim
Subject: My current work and a silly idea
Date: Sat, 20 Oct 2001 14:26:26 +0200
User-agent: Mutt/1.3.23i

I think we can easily and quickly have an Automake which really works
on top of the traces.  Yet, much code get simplified, and works better.
Those who want to give it a try should export amtraces=autoconf,
and of course use 2.52 (or better).

There are still a few macros which are not yet traced, but support is
forthcoming and straightforward to implement.

Many tests are still failing for lack of realism.  For instance, u
to know it was enough for Automake to see that there is the string
AC_PROG_LIBTOOL somewhere to imagine it is run.  Now that we use traces,
it must be expanded, hence *it must be defined*.

I don't know if I should provide a stupid definition of AC_PROG_LIBTOOL
(in which case, this pseudo definition should take care of the AC_SUBST
that LIBTOOL does, otherwise something else will fail, of course), or
do what I promote: realistic tests, i.e., really have libtool.m4.

But then, we $need_libtool in the appropriate tests, which is OK,
but the hard thing being the ACLOCAL invocation: it points to Automake's
build tree only, so it cannot see libtool.m4 installed somewhere.
I don't know yet how to do this properly.  Having cumulative -I in aclocal
come to my mind :(  Or maybe add a -I to the --print-ac-dir of the installed
aclocal?  Sounds good.

Of course gettext tests are affected similarly.

Now for a stupid idea.

Why do we 

if FOO
FOO = foo
endif

=>

@address@hidden = foo

instead of

$(FOO_TRUE)FOO = foo

and leave a plain AC_SUBST definition of FOO_TRUE?  That way, real
hard core checkers could play *dynamically* with conditions.  But I
guess there are some Makes out there which don't like this. Are there?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]