Re: confdefs.h not being included by AC_LANG_SOURCE()

[Brian J. Murrell]

On Tue, 2010-03-02 at 22:35 +0100, Ralf Wildenhues wrote: 
> 
> So you use Autoconf's AC_LANG_SOURCE but your own version of
> AC_LANG_CONFTEST,

Yes, it would seem so.  You will have to excuse my lack of decisiveness
on this.  I am more-or-less just getting to the party.  :-)

> and the fact that an optimization changed
> the latter to do part of the work of the former in Autoconf,

Ahhh.  So that's what changed.

> but your variant of the *CONFTEST macro doesn't do that, breaks
> your code, and is the regression.

Indeed.

> First off, unless your real LB_LINUX_CONFTEST looks differently,

No, in fact it is exactly as I posted.

> you should easily be able to work around the issue by something
> like
>   AC_DEFUN([LB_LINUX_CONFTEST], m4_defn([AC_LANG_CONFTEST]))

Does that have the same effect as simply using AC_LANG_CONFTEST directly
as a replacement for LB_LINUX_CONFTEST?  TBH, I don't know why we have
our own LB_LINUX_CONFTEST but if we don't really need it, I'd be just as
amenable to getting rid of it and using more from upstream.

> which I think should work with both old and new Autoconf.

I tested the new one, and it seems to have the desired effect -- that is
directly replacing LB_LINUX_CONFTEST with AC_LANG_CONFTEST. 

> Second, I do think this is a regression, as our documentation
> pretty clearly states that AC_LANG_SOURCE is the one expanding
> all the AC_DEFINEs seen so far.  I do however also think that
> the old code was ugly and hackish.

Ahhh.  That old rock and hard place.  Clean up the code or keep the API.
I hate when that happens.

As a sidebar, as you can start to see and probably guess, we have
written a boatload of macros to deal with autoconf and the linux kernel
environment.  We'd of course prefer to just use macros that came from
upstream, if they existed.  They don't, right?  :-)  I'm not just
totally missing them am I?

Is there a particular reason why a library of linux kernel macros
doesn't exist, beyond the obvious case that simply nobody has
contributed any?  Or is there a philosophical reason not to build such a
library within the autoconf project itself?

Cheers and thanx much for bearing with me on all of this.

b.

signature.asc
Description: This is a digitally signed message part