Re: Automake shooting in its foot
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> The patch below gives this on the very CVS Automake package: Akim> * m4/depend.m4 (AM_DEPENDENCIES): Don't leave `AC_PROG_CC' etc. in Akim> clear. Akim> * m4/init.m4: Likewise. Akim> * m4/sanity.m4: s/conftestfile/conftest.file/. Please check this in. Tom
Re: Automake shooting in its foot
> "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes: Tim> However, Emacs Lisp also has 'defadvice' which allows you to Tim> attach arbitrary code to an existing function in different Tim> ways. I must admit that whole advice thing strikes me as a little Tim> insane; it's probably quite powerful though. Advice is very, very useful in some situations. I've used it with Tcl programs I've written to good effect. However, overuse of advice makes for unreadable and unmaintainable code. It should definitely only be used in a small number of situations. I'd guess it would make sense to have some advice-like capability in autoconf. I've certainly wanted it more than once. Tom
RE: Automake shooting in its foot
> Morten> Emacs Lisp comes to mind.. ;-) > > Not exactly: AFAIK, you can't freely hook whatever function: you hook > on existing hooks. Right? Yes the 'hook' concept in Emacs Lisp requires a function to explicitly run those hooks, i.e. hooks are only available if the person writing a routine makes them available. However, Emacs Lisp also has 'defadvice' which allows you to attach arbitrary code to an existing function in different ways. I must admit that whole advice thing strikes me as a little insane; it's probably quite powerful though.
Re: Automake shooting in its foot
> "Morten" == Morten Eriksen <[EMAIL PROTECTED]> writes: Morten> Akim, >> 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. [...] Morten> Emacs Lisp comes to mind.. ;-) Not exactly: AFAIK, you can't freely hook whatever function: you hook on existing hooks. Right?
Re: Automake shooting in its foot
Akim, > 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. [...] Emacs Lisp comes to mind.. ;-) Regards, Morten
Re: Automake shooting in its foot
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> Worst case, we can break AC_DEFUNed macros into two macros, Alexandre> one with the actual name, that contains the prologue and Alexandre> the epilogue and, between them, an invocation of another Alexandre> macro, containing the actual code. Then, hooking something Alexandre> before or after a pro/epi macro would be just a matter of Alexandre> pre/appending the code to this other macro. We absolutely agree: all the solutions which seem sound are expensive. This one being the a priori cleanest _if_ we really want to establish hooks for all the macros in the world. In the case of AC_PROG_CC and the like, I'm no sure that's what we want: given that it comprises several very different steps, I wouldn't be surprised that Libtool and Automake would like to insert themselves at different levels. Not to mention the order between Libtool and Automake hooks themselves. Alexandre> The good thing is that, when they break, people notice it Alexandre> immediately. :) :) :) Very true!
Re: Automake shooting in its foot
On Jan 24, 2001, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> In which case, we might attempt to match pro/epi in the
Alexandre> defn and insert the hooks before/after the actual DEFUN,
Alexandre> i.e., between pro and epi.
> Oh, just that? ;)
I have no idea whether it's hard to do.
Worst case, we can break AC_DEFUNed macros into two macros, one with
the actual name, that contains the prologue and the epilogue and,
between them, an invocation of another macro, containing the actual
code. Then, hooking something before or after a pro/epi macro would
be just a matter of pre/appending the code to this other macro.
> I understand the goal was noble and user oriented. But I find it
> extremely dangerous.
Point taken. We have to be careful not to break it. So far, it's
worked moderately well. The good thing is that, when they break,
people notice it immediately.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Automake shooting in its foot
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> Only if the macro is AC_DEFUNed. Well, since we're referring to AC_REQUIRE'd macros etc., they are :) Or where you talking about the cost? Then, yes, agreed, only for AC_DEFUN'd macros. ~/src/ace % ace -i -t m4_define:define -t m4_defun:defun In which case, we might attempt to match pro/epi in the Alexandre> defn and insert the hooks before/after the actual DEFUN, Alexandre> i.e., between pro and epi. Oh, just that? ;) >> 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. Alexandre> It was the only way to achieve a design decision in Alexandre> automake (automatic dependency tracking) and libtool Alexandre> (automatic compiler configuration). Sorry you didn't like Alexandre> it. I understand the goal was noble and user oriented. But I find it extremely dangerous. Since these are macros which are probably the most AC_REQUIRE's the pro/epi is extremely important, and I'm sure we don't really envision all the pitfalls around there. Not to mention the hair I had to keep in CVS Autoconf so that it still works today. Alexandre> But unless autoconf supplies clean manners to do what is Alexandre> needed, people (myself included, or should I say especially Alexandre> myself) will find ways around the limitations. I definitely agree. I would certainly not diminish the responsibility of Autoconf in here. Nothing was prepared to that, and nobody is to blame for the current state. I apologize if I gave the impression I was against people: I'm against the code. I'm really hoping to open the compiler checking macros to the needed hooks. Or any other solution. The thing is, someday the Autotools must make tabula rasa and synchronize, and listen to each other. >> 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. Alexandre> Except those insane folks that came up with OO, right? :-) Groumph. Well, one point :)
Re: Automake shooting in its foot
The patch below gives this on the very CVS Automake package:
% diff Makefile.in Makefile.in.old
63a64,67
> CC = @CC@
> CPP = @CPP@
> CXX = @CXX@
> CXXCPP = @CXXCPP@
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* m4/depend.m4 (AM_DEPENDENCIES): Don't leave `AC_PROG_CC' etc. in
clear.
* m4/init.m4: Likewise.
* m4/sanity.m4: s/conftestfile/conftest.file/.
Index: Makefile.in
===
RCS file: /cvs/automake/automake/Makefile.in,v
retrieving revision 1.242
diff -u -u -r1.242 Makefile.in
--- Makefile.in 2000/12/23 21:42:43 1.242
+++ Makefile.in 2001/01/24 14:20:18
@@ -61,10 +61,6 @@
AMDEP = @AMDEP@
AMTAR = @AMTAR@
AWK = @AWK@
-CC = @CC@
-CPP = @CPP@
-CXX = @CXX@
-CXXCPP = @CXXCPP@
DEPDIR = @DEPDIR@
MAKEINFO = @MAKEINFO@
PACKAGE = @PACKAGE@
Index: aclocal.m4
===
RCS file: /cvs/automake/automake/aclocal.m4,v
retrieving revision 1.47
diff -u -u -r1.47 aclocal.m4
--- aclocal.m4 2000/12/23 21:42:43 1.47
+++ aclocal.m4 2001/01/24 14:20:22
@@ -15,8 +15,16 @@
# some checks are only needed if your package does certain things.
# But this isn't really a big deal.
-# serial 3
+# serial 6
+
+# There are a few dirty hacks below to avoid letting `AC_PROG_CC' be
+# written in clear, in which case automake, when reading aclocal.m4,
+# will think it sees a *use*, and therefore will trigger all it's
+# C support machinery. Also note that it means that autoscan, seeing
+# CC etc. in the Makefile, will ask for an AC_PROG_CC use...
+
+# We require 2.13 because we rely on SHELL being computed by configure.
AC_PREREQ([2.13])
# AC_PROVIDE_IFELSE(MACRO-NAME, IF-PROVIDED, IF-NOT-PROVIDED)
@@ -36,8 +44,7 @@
# AM_INIT_AUTOMAKE(PACKAGE,VERSION, [NO-DEFINE])
# --
AC_DEFUN([AM_INIT_AUTOMAKE],
-[dnl We require 2.13 because we rely on SHELL being computed by configure.
-AC_REQUIRE([AC_PROG_INSTALL])dnl
+[AC_REQUIRE([AC_PROG_INSTALL])dnl
# test to see if srcdir already configured
if test "`CDPATH=:; cd $srcdir && pwd`" != "`pwd`" &&
test -f $srcdir/config.status; then
@@ -69,38 +76,42 @@
AC_REQUIRE([AC_PROG_MAKE_SET])dnl
AC_REQUIRE([AM_DEP_TRACK])dnl
AC_REQUIRE([AM_SET_DEPDIR])dnl
-AC_PROVIDE_IFELSE([AC_PROG_CC],
+AC_PROVIDE_IFELSE([AC_PROG_][CC],
[AM_DEPENDENCIES(CC)],
- [define([AC_PROG_CC],
- defn([AC_PROG_CC])[AM_DEPENDENCIES(CC)])])dnl
-AC_PROVIDE_IFELSE([AC_PROG_CXX],
+ [define([AC_PROG_][CC],
+ defn([AC_PROG_][CC])[AM_DEPENDENCIES(CC)])])dnl
+AC_PROVIDE_IFELSE([AC_PROG_][CXX],
[AM_DEPENDENCIES(CXX)],
- [define([AC_PROG_CXX],
- defn([AC_PROG_CXX])[AM_DEPENDENCIES(CXX)])])dnl
+ [define([AC_PROG_][CXX],
+ defn([AC_PROG_][CXX])[AM_DEPENDENCIES(CXX)])])dnl
])
#
# Check to make sure that the build environment is sane.
#
+# serial 3
+
+# AM_SANITY_CHECK
+# ---
AC_DEFUN([AM_SANITY_CHECK],
[AC_MSG_CHECKING([whether build environment is sane])
# Just in case
sleep 1
-echo timestamp > conftestfile
+echo timestamp > conftest.file
# Do `set' in a subshell so we don't clobber the current shell's
# arguments. Must try -L first in case configure is actually a
# symlink; some systems play weird games with the mod time of symlinks
# (eg FreeBSD returns the mod time of the symlink's containing
# directory).
if (
- set X `ls -Lt $srcdir/configure conftestfile 2> /dev/null`
- if test "[$]*" = "X"; then
+ set X `ls -Lt $srcdir/configure conftest.file 2> /dev/null`
+ if test "$[*]" = "X"; then
# -L didn't work.
- set X `ls -t $srcdir/configure conftestfile`
+ set X `ls -t $srcdir/configure conftest.file`
fi
- if test "[$]*" != "X $srcdir/configure conftestfile" \
- && test "[$]*" != "X conftestfile $srcdir/configure"; then
+ if test "$[*]" != "X $srcdir/configure conftest.file" \
+ && test "$[*]" != "X conftest.file $srcdir/configure"; then
# If neither matched, then we have a broken ls. This can happen
# if, for instance, CONFIG_SHELL is bash and it inherits a
@@ -110,7 +121,7 @@
alias in your environment])
fi
- test "[$]2" = conftestfile
+ test "$[2]" = conftest.file
)
then
# Ok.
@@ -122,31 +133,42 @@
rm -f conftest*
AC_MSG_RESULT(yes)])
+
+# serial 2
+
# AM_MISSING_PROG(NAME, PROGRAM)
-AC_DEFUN([AM_MISSING_PROG], [
-AC_REQUIRE([AM_MISSING_HAS_RUN])
+# --
+AC_DEFUN([AM_MISSING_PROG],
+[AC_REQUIRE([AM_MISSING_HAS_RUN])
$1=${$1-"${am_missing_run}$2"}
AC_SUBST($1)])
+
+# AM_MISSING_INSTALL_SH
+# -
# Like AM_MISSING_PROG, but only looks for install-sh.
-# AM_MISSING_INSTALL_SH()
-AC_DEFUN([AM_MISSING_INSTALL_SH], [
-AC_REQUIRE([AM_MISSING_HAS_RUN])
+AC_DE
Re: Automake shooting in its foot
On Jan 24, 2001, Akim Demaille <[EMAIL PROTECTED]> wrote:
> So to run a hook you need to insert something *inside* the pro/epi
> pair.
Only if the macro is AC_DEFUNed. In which case, we might attempt to
match pro/epi in the defn and insert the hooks before/after the actual
DEFUN, i.e., between pro and epi.
> 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.
It was the only way to achieve a design decision in automake
(automatic dependency tracking) and libtool (automatic compiler
configuration). Sorry you didn't like it. But unless autoconf
supplies clean manners to do what is needed, people (myself included,
or should I say especially myself) will find ways around the
limitations.
> 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.
Except those insane folks that came up with OO, right? :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Automake shooting in its foot
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> On Jan 24, 2001, Akim Demaille <[EMAIL PROTECTED]> wrote: >>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> >>> 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.
Re: Automake shooting in its foot
On Jan 24, 2001, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> 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.
Expensive?
AC_DEFUN([AC_HOOK],[define([$1], [$2]defn([$1])[$3])])
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Automake shooting in its foot
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> 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. But your right, the way out is probably more generic than this. But we have plenty of time before :)
Re: Automake shooting in its foot
On Jan 24, 2001, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> Meanwhile, can't we just hide the uses of AC_PROG_CC and
Alexandre> _CXX from automake by adding ][ in the middle of their
Alexandre> names?
> Right, but the code is already so hairy that I wondered whether I
> wanted to add more crap into it. If you think it's OK
I think it's ok. But I agree the code is messy. We need
AC_HOOK(MACRO, BEFORE, AFTER) in autoconf.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Automake shooting in its foot
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> Meanwhile, can't we just hide the uses of AC_PROG_CC and Alexandre> _CXX from automake by adding ][ in the middle of their Alexandre> names? Right, but the code is already so hairy that I wondered whether I wanted to add more crap into it. If you think it's OK, I'll do.
Re: Automake shooting in its foot
On Jan 23, 2001, [EMAIL PROTECTED] wrote:
> So, IMHO, we have just no issue until we release an autoconf --trace
> aware automake. And frankly, I can't wait :) Automake will be much
> shorter (less hard coded knowledge on Autoconf), more robust (less
> hard coded knowledge on Autoconf), and more extendible (less hard
> coded knowledge on Autoconf).
:-)
Meanwhile, can't we just hide the uses of AC_PROG_CC and _CXX from
automake by adding ][ in the middle of their names?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Automake shooting in its foot
I tracked down the CXX definition in the fileutils' Makefile.ins, and it's damned stupid... Automake comes with its own set of macros, for instance to set up AM_DEPENDENCIES. Whoever uses automake will include these macros in aclocal.m4. Then automake, when scanning aclocal.m4 will find AC_PROG_CC, AC_PROG_CXX etc. in there, and will conclude that the package uses CC, CXX etc. and will define those vars. Seeing this autoscan will ask for an actual use of AC_PROG_CC, since it knows for real what is used and what is not: it uses autoconf's --trace... Actually it is just the same when running autoscan on Automake: because of aclocal.m4 you'll have: ~/src/automake-1.4c % ../ace/autoscan -A ../ace 0:35 remo warning: missing AC_PROG_CC wanted by: Makefile.in:64 m4/Makefile.in:64 tests/Makefile.in:64 warning: missing AC_PROG_CPP wanted by: Makefile.in:65 m4/Makefile.in:65 tests/Makefile.in:65 warning: missing AC_PROG_CXX wanted by: Makefile.in:66 m4/Makefile.in:66 tests/Makefile.in:66 So, IMHO, we have just no issue until we release an autoconf --trace aware automake. And frankly, I can't wait :) Automake will be much shorter (less hard coded knowledge on Autoconf), more robust (less hard coded knowledge on Autoconf), and more extendible (less hard coded knowledge on Autoconf). It'd be great if the Autotools could decide for real that once their 2.50, 1.5 and 1.4 version release, we should make a stop, releasing about the same packages with very few changes, but requiring 2.50 or 2.51. Automake will require autoconf --trace and drop dead compatibility with older Autoconves, and Libtool too, taking advantage of a decided and clean means to hook its stuff to Autoconf's AC_PROG_CC etc. (likewise for Automake's dependency tracking macros). AC_PROG_CC and the like are overloaded to death, and I don't want to be there when they blow out.
