>>> "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
