[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AC_CONFIG_LIBOBJ_DIR
From: |
Russ Allbery |
Subject: |
Re: AC_CONFIG_LIBOBJ_DIR |
Date: |
Wed, 16 Aug 2006 11:20:26 -0700 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux) |
Ralf Wildenhues <address@hidden> writes:
> * Russ Allbery wrote on Tue, Aug 15, 2006 at 07:19:10PM CEST:
>> A while back, I asked about Automake support for AC_CONFIG_LIBOBJ_DIR
>> in the context of using Automake to support a non-recursive build of a
>> package. The result of the discussion was that Automake required some
>> functionality that was new in Autoconf 2.60 in order to support this
>> properly.
>>
>> Since then, Autoconf 2.60 has been released, so I want to inquire again
>> about the status of this support. Right now, one of my packages will
>> only build properly with a patched Automake because of this missing
>> feature, and I'd like to get back to using a standard Automake release.
> The CVS version of Automake has AC_CONFIG_LIBOBJ_DIR support not in
> 1.9.6. Is that sufficient for your needs? IOW, are you asking when
> 1.10 will be ready? (Not that I would be able to answer that...)
I'm not sure. I don't have a way to easily test a CVS version of Automake
right now without spending more time setting it up than I really have to
spare from current projects. :/ The question that I have is specifically
around using it in conjunction with non-recursive builds, where there's a
single Makefile.am at the top of the source tree and all objects are
referred to by their full paths. Automake would need to know to prepend
AC_CONFIG_LIBOBJ_DIR to the path to the objects in AC_LIBOBJ and generate
appropriate build rules for this to work the way that it seems that it
should.
> The patch you posted has not found its way into CVS Automake; do you
> need that? (If so, showing one of your packages or, even better, a
> small example package for its need would help.)
The patch itself allows Automake to cope with an AC_LIBOBJ value that is a
relative path rather than a simple filename. Without this patch, Automake
would claim that util/snprintf.c doesn't exist even though it does. I
personally believe this is an appropriate change to make regardless of the
status of AC_CONFIG_LIBOBJ_DIR support, but with the latter, my need for
this patch would go away.
I essentially gave an example package in my previous message, in that if
you put together a configure script and Makefile.am with those lines,
you'll see the problem. The package that I can't currently build with a
released Automake is at:
<http://www.eyrie.org/~eagle/software/remctl/>
--
Russ Allbery (address@hidden) <http://www.eyrie.org/~eagle/>