Re: AC_FUNC_ALLOCA -- where to get alloca.c?

[Simon Josefsson]

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.