[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: confdefs.h not being included by AC_LANG_SOURCE()
From: |
Brian J. Murrell |
Subject: |
Re: confdefs.h not being included by AC_LANG_SOURCE() |
Date: |
Tue, 02 Mar 2010 17:01:32 -0500 |
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