Re: recursive configure and some $ac_highest_top_srcdir?

[Ralf Wildenhues]

* Steffen Dettmer wrote on Wed, Oct 21, 2009 at 11:26:22AM CEST:
> when using recursive configure via AC_CONFIG_SUBDIRS, how to know
> (in a sub-configure) where the top directory is?

Good question.  If your project structure has a variable level of upper
configure scripts then, as you describe, you cannot hard-code this.

However, if we follow the ideas behind configure recursion, you also
should not expect that above the top-most level configure script is one
that comes from your project: one goal of the uniform argument scheme
of configure scripts is that I could take your project, plus several
others, put them side by side in subdirectories, and write an upper
level configure.ac:
  AC_INIT([super-package])
  AC_CONFIG_SUBDIRS([your-package other-package ...])
  AC_OUTPUT

and your package should cope with that.

This explains why $ac_highest_top_srcdir should not come from Autoconf.

For absolute names, you can easily solve this issue in your own package
by adding something like
  if test "${highest_abs_top_srcdir+set}" != set; then
    highest_abs_top_srcdir=`cd "$srcdir" && pwd`
    export highest_abs_top_srcdir
  fi

to each configure.ac that could potentially serve as the highest one in
your package tree.  (Note you still have to propagate the value from
configure to makefiles etc.)

Dealing with not-necessarily-absolute names looks like it needs Autoconf
support.  But even then it seems quite tricky.

It would be easy to have an Autoconf API that lets configure correct a
variables or a command-line argument by the reverse path
($ac_top_builddir_sub) upon configure recursion in _AC_OUTPUT_SUBDIRS.

But would this be elegant, too?  Ideally, it should be possible to
transport a
  --with-foo-package=../foo

through a couple of sub configure scripts that each don't care about the
--with-foo-package switch at all, thus won't have any annotation for it
either.  OTOH, we certainly cannot correct all --with-* switches that
way; while it would have been cool to specify such semantics from the
beginning, it's far too late to do so now.

Maybe you can live with something like this: pass absolute directories
to the --with-* flags.  In the macros that deal with their values, try
to relativize the directories.  There exist a few ways to do that; they
typically have problems with symlinks though, and might need adjustment
for w32-like drive specs.  The one I know is in gnulib-tool, but I think
I saw a perl version somewhere too.

> Is there any way to pass some "--topsrcdir=../$topsrcdir" to the
> subconfigures?  topdir would start with "." if not set and
> extended in each level.

Not currently, but as I said, something like that could easily be added.

> Of course it would be more complicated
> for things like AC_CONFIG_SUBDIRS([two/dir_levels]).

Not really.  If you look at the code generated for a AC_CONFIG_SUBDIRS,
there is a $ac_top_build_prefix computed on the fly which computes the
needed string.  It's just that you couldn't get at it currently.

> This also would be needed by configure to find config.cache, but
> this is solved by "--cache_file=../config.cache", which does not
> help much in the "general case" (like custom global files etc).

Yep.

> I understand that such an $ac_highest_top_srcdir would make it
> complicated (or even impossible) to run a sub-configure directly.

No, I don't see that.

> We could "count double-dot levels" in --srcdir or "detect" the
> depth by counting dots in --cache_file and prepend it to
> $ac_top_srcdir, but this sucks and I guess it is likely to cause
> other trouble.

That won't work if I run this with the toplevel:
  mkdir build
  cd build
  ../configure
  ^^^
(one more level than you'd think).

> Absolute paths in --with-me fail at least when using WINE.

Is that some issue in Wine or in Autoconf, or elsewhere?
The typical thing to write is
  case $file in
  [\\/]* | ?:[\\/]* ) $file is absolute ...;;
  *) $file is relative ...;;
  esac

> NB: It already is impossible to AC_CHECK_XXX for things from package
>     (it would be cool to be able to check if package2 has this
>     and that header or some FUNC, but this won't work, because
>     -I$(top_srcdir)/../package2/src needs "make" to be evaluated,
>     so compiler would try a directory "$(top_srcdir)", which does
>     not exist, and thus never finds the header of course).
>     Because of the same problem with compiler wrappers
>     ("CCLD=$(top_srcdir)/../package2/applinkwrap.sh" etc) we
>     cannot check if the wrappers do work.

But shouldn't absolute names work as arguments to -I, or in CCLD
settings?

Cheers,
Ralf