A release with LIBOBJDIR?
Hello, current CVS versions of Autoconf and Automake use make variable LIBOBJDIR, to enable using AC_LIBOBJ with non-recursive makefiles. I think this is not the best possible solution to the problem. I hoped to submit an alternative solution, which would mean that LIBOBJDIR could have beed removed then. It became clear that the solution won't be available before the release of Autoconf 2.60 and Automake 1.10. But if we release versions with LIBOBJDIR, we will be bounded to support it in future releases, even in case that it will become redundant. That is why I'd like to ask you to consider marking the feature as experimental, and adding a warning that it may disappear in future releases. (Below are some details about the alternative solution I have in mind.) Have a nice day, Stepan -- The sketch of the alternative solution -- It is often requested that AC_LIBOBJ should support more than one libobj directory. (Examples were presented which show how this feature would make some projects more manageable.) I think that the best way to implement this is let Autoconf collect all the objects and then filter them for various output files. Note that we already have variables which have different values in different output files, eg. top_srcdir. Note also that Autoconf already does some manipulation with LIBOBJS before writing output files, so this is not new either. I imagine that for each declared libobj subdirectory, Autoconf would filter out everything but the objects from that directory. And for the top-level makefile, LIBOBJS would contain all the objects, with their relative path. As you can see, this would also solve the problemof non-recursive makefiles, rendering LIBOBJDIR redundant.
Re: A release with LIBOBJDIR?
Hi Stepan, * Stepan Kasal wrote on Sat, Apr 01, 2006 at 10:42:23PM CEST: > [ LIBOBJDIR ] > > That is why I'd like to ask you to consider marking the feature > as experimental, and adding a warning that it may disappear in > future releases. Could you post a patch/patches to this end? (Since this issue does not touch released versions of either tool (yet), the discussion may better belong on the *-patches lists.) > (Below are some details about the alternative solution I have in mind.) FWIW, I probably don't agree with all the details in this alternative approach; but that can be discussed at another time. The question is rather whether Autoconf and Automake maintainers agree with the general point above. Cheers, Ralf
Re: A release with LIBOBJDIR?
Stepan Kasal <[EMAIL PROTECTED]> writes: > That is why I'd like to ask you to consider marking the feature > as experimental, and adding a warning that it may disappear in > future releases. That sounds fine to me, but we need a real patch.
Re: A release with LIBOBJDIR?
>>> "SK" == Stepan Kasal <[EMAIL PROTECTED]> writes: SK> current CVS versions of Autoconf and Automake use make variable SK> LIBOBJDIR, to enable using AC_LIBOBJ with non-recursive makefiles. Among other uses. SK> But if we release versions with LIBOBJDIR, we will be bounded to SK> support it in future releases, even in case that it will become SK> redundant. Let's worry when we get there. [...] SK> It is often requested that AC_LIBOBJ should support more than one SK> libobj directory. (Examples were presented which show how this SK> feature would make some projects more manageable.) The need is to split required sources/objects into groups, for instance to create different libraries. Using multiple directories is just one way to do it. The plan discussed when LIBOBJDIR was introduced was to have multiple LIBOBJS-like variables (and hence multiple LIBOBJDIR variables), allowing you to build different libraries even if all your sources are in the same directory. This can be introduced without breaking the existing LIBOBJS/LIBOBJDIR interface. SK> I imagine that for each declared libobj subdirectory, Autoconf would SK> filter out everything but the objects from that directory. And for SK> the top-level makefile, LIBOBJS would contain all the objects, with SK> their relative path. What about non-recursive Makefiles that are not at the top-level? What about recursive Makefiles that uses @LIBOBJS@ from different directories directly without creating an archive? SK> As you can see, this would also solve the problemof non-recursive SK> makefiles, rendering LIBOBJDIR redundant. I clearly don't think so :) -- Alexandre Duret-Lutz Shared books are happy books. http://www.bookcrossing.com/friend/gadl
Re: A release with LIBOBJDIR?
Hello, On Sun, Apr 02, 2006 at 09:28:53PM +0200, Alexandre Duret-Lutz wrote: > >>> "SK" == Stepan Kasal <[EMAIL PROTECTED]> writes: > SK> But if we release versions with LIBOBJDIR, we will be bounded to > SK> support it in future releases, even in case that it will become > SK> redundant. > > Let's worry when we get there. OK, I'll raise this issue when we get close to Autoconf 2.60. > The need is to split required sources/objects into groups, for > instance to create different libraries. Using multiple > directories is just one way to do it. Another need is to split the sources to multiple directories, to make the tree more maintainable. > The plan discussed when LIBOBJDIR was introduced was to have > multiple LIBOBJS-like variables (and hence multiple LIBOBJDIR > variables), I remember the discussion, but I always thought the tone was: ``well, this would require multiple LIBOBJDIR-like variables, so think twice''. I was scared by the idea of multitude of magic variables; thank you for explaining me your view. Alexandre, you showed me that my proposal needs more thought, thanks. Let's put it off for now, Stepan,
Re: A release with LIBOBJDIR?
* Stepan Kasal wrote on Mon, Apr 03, 2006 at 10:03:16PM CEST:
> On Sun, Apr 02, 2006 at 09:28:53PM +0200, Alexandre Duret-Lutz wrote:
> > >>> "SK" == Stepan Kasal <[EMAIL PROTECTED]> writes:
> > SK> But if we release versions with LIBOBJDIR, we will be bounded to
> > SK> support it in future releases, even in case that it will become
> > SK> redundant.
> >
> > Let's worry when we get there.
> Alexandre, you showed me that my proposal needs more thought, thanks.
> Let's put it off for now,
Without any desire to discuss possible solutions or issues with
LIBOBJDIR now, I'd still think it good style to let the user know
that this may not be the end of the story, so that at least I
don't feel quite as guilty in case something incompatible will
happen here. Any objections against the patch below (to Autoconf)?
Cheers,
Ralf
* NEWS, doc/autoconf.texi (AC_LIBOBJ vs LIBOBJS): Mark
`LIBOBJDIR' as experimental.
Index: NEWS
===
RCS file: /cvsroot/autoconf/autoconf/NEWS,v
retrieving revision 1.357
diff -u -r1.357 NEWS
--- NEWS5 Apr 2006 22:41:36 - 1.357
+++ NEWS6 Apr 2006 22:06:35 -
@@ -86,6 +86,7 @@
Object names added to these variables are now prefixed with `${LIBOBJDIR}',
as in `${LIBOBJDIR}alloca.o'. LIBOBJDIR is meant to be defined from
`Makefile.in' in case the object files lie in a different directory.
+ The LIBOBJDIR feature is experimental.
** autoreconf
Supports --no-recursive now.
Index: doc/autoconf.texi
===
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.986
diff -u -r1.986 autoconf.texi
--- doc/autoconf.texi 6 Apr 2006 17:51:22 - 1.986
+++ doc/autoconf.texi 6 Apr 2006 22:06:44 -
@@ -16405,6 +16405,7 @@
can be referenced from any @file{Makefile.am}. Even without Automake,
arranging for @code{LIBOBJDIR} to be set correctly will enable
referencing @code{LIBOBJS} and @code{LTLIBOBJS} in another directory.
+The @code{LIBOJBDIR} feature is experimental.
@node AC_FOO_IFELSE vs AC_TRY_FOO
Re: A release with LIBOBJDIR?
Ralf Wildenhues <[EMAIL PROTECTED]> writes: > * NEWS, doc/autoconf.texi (AC_LIBOBJ vs LIBOBJS): Mark > `LIBOBJDIR' as experimental. That change looks good to me; thanks.
Re: A release with LIBOBJDIR?
* Paul Eggert wrote on Sun, Apr 09, 2006 at 09:13:38AM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
>
> > * NEWS, doc/autoconf.texi (AC_LIBOBJ vs LIBOBJS): Mark
> > `LIBOBJDIR' as experimental.
>
> That change looks good to me; thanks.
Applied. For autoconf-patches reference, here's a copy.
Thanks,
Ralf
* NEWS, doc/autoconf.texi (AC_LIBOBJ vs LIBOBJS): Mark
`LIBOBJDIR' as experimental.
Index: NEWS
===
RCS file: /cvsroot/autoconf/autoconf/NEWS,v
retrieving revision 1.357
diff -u -r1.357 NEWS
--- NEWS5 Apr 2006 22:41:36 - 1.357
+++ NEWS6 Apr 2006 22:06:35 -
@@ -86,6 +86,7 @@
Object names added to these variables are now prefixed with `${LIBOBJDIR}',
as in `${LIBOBJDIR}alloca.o'. LIBOBJDIR is meant to be defined from
`Makefile.in' in case the object files lie in a different directory.
+ The LIBOBJDIR feature is experimental.
** autoreconf
Supports --no-recursive now.
Index: doc/autoconf.texi
===
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.986
diff -u -r1.986 autoconf.texi
--- doc/autoconf.texi 6 Apr 2006 17:51:22 - 1.986
+++ doc/autoconf.texi 6 Apr 2006 22:06:44 -
@@ -16405,6 +16405,7 @@
can be referenced from any @file{Makefile.am}. Even without Automake,
arranging for @code{LIBOBJDIR} to be set correctly will enable
referencing @code{LIBOBJS} and @code{LTLIBOBJS} in another directory.
+The @code{LIBOJBDIR} feature is experimental.
@node AC_FOO_IFELSE vs AC_TRY_FOO
