[Top][All Lists]

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

Re: weird AC_REQUIRE expansion issue

From: Ralf Wildenhues
Subject: Re: weird AC_REQUIRE expansion issue
Date: Mon, 29 Aug 2005 15:26:03 +0200
User-agent: Mutt/1.4.1i

Hi Stepan,

Thanks for your quick reply!

* Stepan Kasal wrote on Mon, Aug 29, 2005 at 01:22:18PM CEST:
> On Mon, Aug 29, 2005 at 12:20:02PM +0200, Ralf Wildenhues wrote:
> > A project uses subdir-objects, calls AC_PROG_CC before calling
> > AM_PROG_CC_C_O, yet the code of AC_PROG_CC_C_O (which is AC_REQUIREd by
> > the Automake macro) gets expanded before the AC_PROG_CC macro.  Thus,
> > $CC is empty and the test fails.
> If you call
> AC_FOO(...,
>   [something
>    ...
>   ])
> where AM_WHATEVER requires AC_PROG_CC_C_O, then AC_PROG_CC_C_O will be
> expanded before the beginning of AC_FOO.
> AC_REQUIRED macros are expanded before the outermost AC_DEFUNed macro.

Darn, I keep forgetting about this.

> You have to do
> AC_FOO(...,
>   [something
>    ...
>   ])
> Does it help?

Sure, you're spot-on.  

But what if I want to achieve something like

[CX_STATUS([compiler checks])

where I can't AC_REQUIRE([CX_STATUS]), because that is supposed to be
used several times, obviously, and also I need to do stuff between
AC_PROG_CC and AM_PROG_CC_C_O (e.g.: store the value of $CC for later
use with AM_PROG_AS)?

Do I have to move away from AC_DEFUNing CX_COMPILER_CHECKS and to just
m4_include'ing the file in question (would be very ugly) to serialize?

> Post your, if the guess is not right.

Good thing I don't have to do that.  It's a mere couple thousand lines,
but the m4_included files make up for another 8000, not including
libtool.m4 (which of course also comes into play).


reply via email to

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