Re: A release with LIBOBJDIR?

[Alexandre Duret-Lutz]

>>> "SK" == Stepan Kasal <address@hidden> 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