autoconf-patches
[Top][All Lists]
Advanced

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

Re: Proto patch for circular dependencies


From: Akim Demaille
Subject: Re: Proto patch for circular dependencies
Date: 12 Oct 2000 10:19:37 +0200
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands)

| On Oct 12, 2000, Akim Demaille <address@hidden> wrote:
| > I'm not sure I understand :(  How would you present this?
| 
| /tmp % ace                                                       nostromo 
11:43
| autoconf: warning: --macrodir is obsolete, use --autoconf-dir
| configure.in:2: AC_REQUIRE: circular dependency of AC_LANG_COMPILER(C)
| configure.in:2:           AC_LANG_COMPILER(C) is required by...
| configure.in:2:          AC_LANG_COMPILER_REQUIRE is expanded from...
| configure.in:2:         AC_LINK_IFELSE is expanded from...
| configure.in:2:        AC_PROG_CC is expanded from...
| configure.in:2:       AC_LANG_COMPILER(C) is expanded from...
| configure.in:2:       AC_LANG_COMPILER(C) is required by...
| configure.in:2:      AC_LANG_COMPILER_REQUIRE is expanded from...
| configure.in:2:     AC_LINK_IFELSE is expanded from...
| configure.in:2:    AC_PROG_CC is expanded from...
| configure.in:2:   the top level
| 
| Hmm...  It doesn't gain us much, and it would probably be relatively
| hard to implement.

At least hairy.

| In any case, if it weren't too hard, I'd probably remove the line:
| 
| configure.in:2:       AC_LANG_COMPILER(C) is expanded from...
| 
| since it's already implied by the `required by' in the following line.

Well, that's what I thought too :)  But I had terrible problems trying
to synchronize the pushdef/popdef.  I gave up.

[Some time passes].

OK, I have this now:

/tmp % ace                                                       nostromo Err 1
configure.in:2: AC_REQUIRE: circular dependency of AC_LANG_COMPILER(C)
configure.in:2:   AC_LANG_COMPILER(C) is required by...
configure.in:2:   AC_LANG_COMPILER_REQUIRE is expanded from...
configure.in:2:   AC_LINK_IFELSE is expanded from...
configure.in:2:   AC_PROG_CC is expanded from...
configure.in:2:   AC_LANG_COMPILER(C) is required by...
configure.in:2:   AC_LANG_COMPILER_REQUIRE is expanded from...
configure.in:2:   AC_LINK_IFELSE is expanded from...
configure.in:2:   AC_PROG_CC is expanded from...
configure.in:2:   the top level

and

/tmp % cat configure.in && ace                                   nostromo Err 1
AC_DEFUN([TOTO], [AC_REQUIRE([TOTO])])
AC_INIT
TOTO
configure.in:3: AC_REQUIRE: circular dependency of TOTO
configure.in:3:   TOTO is required by...
configure.in:3:   TOTO is expanded from...
configure.in:3:   the top level


What changed is the pushdef/popdef pair in _AC_DEFUN_PRO/EPI.  We have
a higher coupling between AC_DEFUN and AC_REQUIRE, but maybe someday
we will have a better means to handle this.

     | # _AC_DEFUN_PRO(MACRO-NAME)
     | # -------------------------
     | # The prologue for Autoconf macros.
     | define([_AC_DEFUN_PRO],
     | [AC_PROVIDE([$1])dnl
=>   | ifelse(defn([_AC_EXPANSION_STACK]), [$1 is required by...], [],
=>   |        [pushdef([_AC_EXPANSION_STACK], [$1 is expanded from...])])dnl
     | pushdef([_AC_EXPANDING($1)], [$1])dnl
     | ifdef([_AC_DIVERT_DUMP],
     |       [AC_DIVERT_PUSH(defn([_AC_DIVERT_DIVERSION]))],
     |       [define([_AC_DIVERT_DUMP], defn([_AC_DIVERT_DIVERSION]))dnl
     | AC_DIVERT_PUSH([PREPARE])])dnl
     | ])
     | 
     | 
     | # _AC_DEFUN_EPI(MACRO-NAME)
     | # -------------------------
     | # The Epilogue for Autoconf macros.  MACRO-NAME only helps tracing
     | # the PRO/EPI pairs.
     | define([_AC_DEFUN_EPI],
     | [AC_DIVERT_POP()dnl
     | ifelse(_AC_DIVERT_DUMP, _AC_DIVERT_DIVERSION,
     |        [undivert(_AC_DIVERT([PREPARE]))dnl
     | undefine([_AC_DIVERT_DUMP])])dnl
=>   | ifelse(defn([_AC_EXPANSION_STACK]), [$1 is required by...], [],
=>   |        [popdef([_AC_EXPANSION_STACK])])dnl
     | popdef([_AC_EXPANDING($1)])dnl
     | ])


Hm, on a second thought, I'm not sure it is a good thing to do that
this way...

We now have:

| /tmp % cat configure.in
| AC_DEFUN([TOTO],
| [AC_REQUIRE([TATA])])
| 
| define([TATA],
| [AC_REQUIRE([TITI])])
| 
| AC_DEFUN([TITI],
| [AC_REQUIRE([TOTO])])
| 
| AC_INIT
| TOTO
| /tmp % ace
| configure.in:11: AC_REQUIRE: circular dependency of TOTO
| configure.in:11:   TOTO is required by...
| configure.in:11:   TITI is required by...
| configure.in:11:   TATA is required by...
| configure.in:11:   TOTO is expanded from...
| configure.in:11:   the top level

where we had this before:

| /tmp % ace
| configure.in:11: AC_REQUIRE: circular dependency of TOTO
| configure.in:11:   TOTO is required by...
| configure.in:11:   TITI is expanded from...
| configure.in:11:   TITI is required by...
| configure.in:11:   TATA is required by...
| configure.in:11:   TOTO is expanded from...
| configure.in:11:   the top level

Notice the difference between AC_DEFUN/define macros.  TITI is
AC_DEFUN'd and you can see it since it has the AC_DEFUN signature over
it (is expanded from...), while TATA is define'd and you can see it
because it's not in the stack.  If I now AC_DEFUN TATA, I get:

| /tmp % ace
| configure.in:11: AC_REQUIRE: circular dependency of TOTO
| configure.in:11:   TOTO is required by...
| configure.in:11:   TITI is expanded from...
| configure.in:11:   TITI is required by...
| configure.in:11:   TATA is expanded from...
| configure.in:11:   TATA is required by...
| configure.in:11:   TOTO is expanded from...
| configure.in:11:   the top level


So yes, it makes a difference.  I tend to think that, at least for
error messages, a bit too much information is OK.

What do you think?



reply via email to

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