automake
[Top][All Lists]
Advanced

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

Re: Automake shooting in its foot


From: Akim Demaille
Subject: Re: Automake shooting in its foot
Date: 24 Jan 2001 14:15:27 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Crater Lake)

>>>>> "Alexandre" == Alexandre Oliva <address@hidden> writes:

Alexandre> On Jan 24, 2001, Akim Demaille <address@hidden> wrote:
>>>>>>> "Alexandre" == Alexandre Oliva <address@hidden>
>>>>>>> writes:
Alexandre> I think it's ok.  But I agree the code is messy.  We need
Alexandre> AC_HOOK(MACRO, BEFORE, AFTER) in autoconf.

>> Wow!  This sounds real hard, or at least, really expansive if we do
>> for all the macros.  I was thinking of hooks for AC_PROG_CC and the
>> like.

Alexandre> Expensive?

Alexandre> AC_DEFUN([AC_HOOK],[define([$1], [$2]defn([$1])[$3])])

No, this is why I'm against all the stuff Libtool and Automake are
doing: you are forgetting that the core of the macro is wrapped in
_epi and _pro.  *That*'s the problem.  In addition you need at least a
dumb check that verifies a hook is not installed after the macro was
expanded.  I agree it's unlikely, but given the freedom people took
with concatenating defn of macros, I'd like to have more sanity
checks.

So to run a hook you need to insert something *inside* the pro/epi
pair.  This is pushing some load on every single AC_DEFUN'ed macros.
ANd that's where I expect a noticeable impact.

This is also why I was thinking of providing the right hooks for
AC_PROG_CC etc.: it's efficient, and we can place the hooks at the
right place, not before or after.

Finally, let me state things clearly: I'm doing this to help people
proceed with their bad habits, but from the beginning I was against
hooking on AC_PROG_CC etc.  There should have been LT_PROG_CC
etc. and no macro redefinition games.

In fact, I am still against generic hooks because that's a bad thing
to do.  Nobody where ever imagine doing this in another programming
language.  Inserting stubs sounds better.



reply via email to

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