autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

recursive configure and some $ac_highest_top_srcdir?


From: Steffen Dettmer
Subject: recursive configure and some $ac_highest_top_srcdir?
Date: Wed, 21 Oct 2009 11:26:22 +0200

Hi,

when using recursive configure via AC_CONFIG_SUBDIRS, how to know
(in a sub-configure) where the top directory is?

I mean, something like automakes $(top_srcdir) inside configure.

NB: This is not $ac_top_srcdir which (as far as I understood)
    should always point to the directory where the running
    configure is (but not the highest parent). For some reason in
    my test configure.in $ac_top_srcdir even is empty but anyway.

I'm afraid I cannot explain my need well...
So I ask again differently:
Is there any way to pass some "--topsrcdir=../$topsrcdir" to the
subconfigures?  topdir would start with "." if not set and
extended in each level. Of course it would be more complicated
for things like AC_CONFIG_SUBDIRS([two/dir_levels]).

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).

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

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.

I have no idea how to address this in a not-to-bad-way.
Where should I look to? Any pointers/proposals/recommendations?



I also try to explain why (I think) we need this.

We usually have a structure like

configuration1/configure
configuration1/package1/configure
configuration1/package2/configure
configuration1/package3/configure

configuration2/configure
configuration2/package1/configure
configuration2/package2/configure
configuration2/package4/configure

(package1 and package2 are reused/shared).

Lets assume package4 depends on package2. Now we have a mechanism
that package4 has some --with-package2 defaulting to
"../package2".

This breaks when needing:
configuration2/configure
configuration2/package1/configure
configuration2/package2/configure
configuration2/package4/configure
configuration2/package5/configure
configuration2/package5/subdir1/configure

with package5 depending on package4 and thus package2. Includes
for example would be something like "-I$(top_srcdir)/../package2/src"
works with automake in package5 but not in package5/subdir1,
because here "-I$(top_srcdir)/../../package2/src" would be
needed.

Additionally, it is impossible to use something like
--with-package2=../../package2, because then it would work in
package5/subdir1 but not in package5 itself (--with options are
same for all configures).

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

NB: Using absolute paths works on unix, but causes tears and
    endless trouble with cygwin or MSYS windows drive letters and
    when using WINE. Since we have some DOS-only compilers, we
    need that and cannot use absolute paths.

Another (at the moment less important) aspect is when package2
has linker wrappers and if they are needed in configure itself.

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.


Sorry for the long big text and thanks for reading it anyway :-)

oki,

Steffen




reply via email to

[Prev in Thread] Current Thread [Next in Thread]