Akim Demaille wrote:
> dv> something that I consider as a real bug in the current interface:
> dv> if the macro A requires the macro B, and the macro B is present in
> dv> configure.in after A, A should not just call B. It should abort at
> dv> autoconf time and nicely ask the package writer to switch the two
> dv> calls.
>
> I personally don't agree. The declarative and almost commutative
I like the "almost" ... ;-)
> nature of configure.in is a strength of Autoconf, and I'd like to keep
> it like this.
C'mon! It is obviously a strength to be commutative, provided that it
doesn't introduce bugs in autoconf. And it does introduce some, because you
simply can't be commutative all the time. You definitely can't pretend that
the current AC_BEFORE / AC_REQUIRE scheme is sufficient. For instance, take
this configure.in script:
,----
| AC_PREREQ(2.14a)
| AC_INIT(configure.in)
| AC_CONFIG_SUBDIRS(sub) dnl #### calls AC_CONFIG_AUX_DIR_DEFAULT
| AM_INIT_AUTOMAKE(test, 1)
| AC_CONFIG_AUX_DIR(aux) dnl #### Wrong: second call to AC_CONFIG_AUX_DIRS
| AC_OUTPUT(Makefile)
`-----
- automake notices the presence of AC_CONFIG_AUX_DIR (line 5) and installs
the missing programs in aux/
- autoconf expands the third line to a piece of code that looks for install.sh
everywhere but in aux/. Running configure hence fails miserably.
The result is that Joe user gets no warning, no error, and a configure
script that fails. He has to read *very carefully* the documentation in order
to find that AC_CONFIG_SUBDIRS /might/ call AC_CONFIG_AUX_DIR. This is not
even explicit in the doc, and for an autoconf newbie, it is not obvious at all
that the order of these two macros is important. And it is dramatically
important.
I'm sorry, but I do call that situation a bug in autoconf. Wouldn't it
be because you end up with several expansions of AC_CONFIG_AUX_DIRS in the
same configure script with different dirs[1], at least because automake cannot
perform its job correctly. There are times you can't be commutative or
redundant, even at levels the random autoconf user shouldn't be aware of, but
this situation is not handled properly, end of the story.
> I see no reason for people to learn too much about Autoconf, we are here to
> this end. And having to learn an order is definitely amongst the less
> fruitful things to learn.
Exactly!!! But your argument is self-contradictory. In the case I
demonstrated above, the user *has* to learn about the order, and that's
exactly what I'm complaining about. It *is* an autoconf failure. If AC_REQUIRE
behaved the Good Way (or if autoconf provided another way to do what is
needed, namely AC_REQUIRE_AND_CHECK_NOT_GIVEN_BELOW), autoconf'ing the above
script would barf with a clear error message, the user would know immediately
what to do, wouldn't have to snarf in the code (neither in the doc) to see
what went wrong. "We are here to this end" (Akim Demaille :-)
> As far as requiring with arguments, it is something which is planned
> in the future of Autoconf, but we are cooling down the development for
> 2.15.
OK.
Footnotes:
[1] which is already a weird thing
--
/ / _ _ Didier Verna http://www.inf.enst.fr/~verna/
- / / - / / /_/ / EPITA / LRDE mailto:[EMAIL PROTECTED]
/_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77
94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99
