Hello Richard, * Richard Ash wrote on Mon, May 26, 2008 at 09:59:17PM CEST: > > > On Sat, 2008-05-24 at 09:41 +0200, Ralf Wildenhues wrote: > > > > * Richard Ash wrote on Fri, May 23, 2008 at 11:31:39PM CEST: > > > > > I seem to have hit a fundamental problem with the way AC_CONFIG_SUBDIRS [...] > > > > Why don't you organize your package in such a way that the top level > > > > configure is just a stub one calling those for lib1, lib2, ..., libN, > > > > and only then the one for your main package? [...] > Under your scheme I have to decide what libraries to configure before > anything else has happened, and indeed before I know the output of any > of those configurations. I still can't express chained dependencies like > the fact I need libvorbis, which depends on libogg, in order to build my > app. If I try to support this, I need three layers of chained configure > scripts... Hmm, ok. Your request for a new macro to run a sub-configure script right away makes more sense to me now. > It's possible to work around, but it seems much more logical to do > if (libX available on system) > USE_LIBX=system > else > configure(libX) > if (libX available locally) > USE_LIBX=local > else > USE_LIBX=no > fi > fi > > Not least because this is only one line (the configure(libX)) different > from what I write for a library that doesn't use pkg-config. I agree > it's possible to design a configure script around the limitations of > AC_CONFIG_SUBIRS and pkg-config. What I'm struggling to comprehend is > why I should have to do this - I thought pkg-config and autoconf were > both supposed to make configuring my program easier, at the moment they > are making life significantly awkward. Well, I don't think anyone has complained about it this plainly. Thanks, Ralf _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
