[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AC_FUNC_ALLOCA -- where to get alloca.c?
From: |
Simon Josefsson |
Subject: |
Re: AC_FUNC_ALLOCA -- where to get alloca.c? |
Date: |
Fri, 21 Nov 2003 05:37:05 +0100 |
User-agent: |
Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) |
Paul Eggert <address@hidden> writes:
> Simon Josefsson <address@hidden> writes:
>
>> Which alloca.c is AC_FUNC_ALLOCA supposed to go with? The one in
>> gnulib requires several xmalloc() and other stuff.
>
> I'd say that it could be any alloca that you like. (The simplest one
> would be malloc. :-)
Ok, I thought there would be a specific alloca.c that the macro had in
mind.
>> The AC_FUNC_ALLOCA test appear rather closely tied to a specific
>> implemention of alloca.c
>
> Yes, that's true. One of the long-term goals is to unify Autoconf
> with that part of gnulib where this would make sense. In the short
> run, though, perhaps it'd make more sense to move most of the guts of
> AC_FUNC_ALLOCA from Autoconf into gnulib.
One feature with the AC_FUNC_ALLOCA macro is that it doesn't use
LIBOBJS. Well, it can be both a bug and a feature, depending on how
you look at it. But I have found it useful, some parts of my package
(e.g., the Nettle low-level crypto library) doesn't use gnulib, but do
require alloca. Adding @ALLOCA@ to that makefile is enough. Libgsasl
itself does not use, e.g., argp, but if I want to use, e.g., xmalloc I
specify @LTLIBOBJ@, which would add other stuff to my library I don't
want. So I sometime wish the @ALLOCA@ approach was more widely
supported. Is it worth the time to make each gnulib module define its
own @ALLOCA@, @GETOPT@, @XMALLOC@ etc? @LTLIBOBJ@ would behave the
same. Perhaps there would be a problem with duplicates -- e.g., if
you want both XMALLOC and ALLOCA you type @ALLOCA@ @XMALLOC@ but if
alloca required xmalloc you would end up with linking xmalloc.o
alloca.o xmalloc.o. I'm not sure this is a problem, but it sounds
like a potential one.