Re: AC_CONFIG_SUBDIRS and pkg-config

[Richard Ash]

On Mon, 2008-05-26 at 19:53 +0200, Ralf Wildenhues wrote:
> * Richard Ash wrote on Sun, May 25, 2008 at 11:14:43PM 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
> > > > that seems to make it most of the way to useless if you want to also use
> > > > pkg-config. Basically, it runs the configure scripts in sub-directories
> > > > after my main configure script has finished, which is useless because I
> > > > want information from those subsidiary configure script to decide how to
> > > > build my application.
> > > 
> > > 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?
> > Plausible, but means that required libraries are treated completely
> > differently to optional ones.
> 
> No, why?  It merely implies an absolute ordering, i.e., no circular
> dependencies.
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...

> > It also doesn't scale to my next problem,
> > which is libraries where we use the local copy if there isn't a system
> > one available. 
> 
> I don't see where that adds any further restrictions.

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.

> > In the end I dug the relevant code out of autoconf/status.m4 that runs
> > the subsidiary configure script and made it into a function that
> > configures just one directory, but does it when the function is called
> > not at some later point. I'll probably send this off the autoconf macro
> > archive in case other people find it useful.
> 
> The problem with this is that this particular code in Autoconf changed
> not too long ago, and is likely to undergo further changes, possibly
> making your macro incompatible with the current or a future version,
> not to speak of past versions.

_AC_SRCDIRS is the only internal macro I use inside AX_CONFIG_DIR,
baring public ones like AC_MSG_NOTICE, AS_MKDIR_P. Removing _AC_SRCDIRS
would not be terribly difficult, so at that point the implementation is
all copied rather than linked to. I'm not clear why this would have
compatibility issues, apart from being potentially confusing if the
behaviour of AC_CONFIG_SUBDIRS changes because the behaviour of
AX_CONFIG_DIR wouldn't.

On the subject of unstable and version dependent things, in order to
work round the fact that I can't get results from other library's
configure script I'm already messing with $ac_configure_args to control
what is built. If I could use the configure results I wouldn't have to
do this, or a number of other cumbersome things (like detecting ALSA
twice, once to find out if my sub-library will need -lalsa in order to
be linked, and once in the sub-library to decide if ALSA support should
be compiled).

If duplication of the code is a problem, then it would be fairly trivial
to express _AC_OUTPUT_SUBDIRS as a loop macro which called AX_CONFIG_DIR
once for each of the directories listed in $subdirs (the list built up
by calls to AC_CONFIG_SUBDIRS). To me this is a more logical piece of
structure - we have a simple, dumb function (what I'm calling
AX_CONFIG_DIR) and then a more complex bu easier to use version for most
people (AC_CONFIG_SUBDIRS) which builds upon it. What's frustrating me
is a lack of control within the public autoconf interface (and a lack of
documentation that means it doesn't say anywhere that AC_CONFIG_SUBDIRS
defers running the configure script until everything else in the
configure script has happened).

Richard