Re: ../configure question

[Guido Draheim]

Es schrieb Troy Cauble:
> 
> I am cleaning up some autoconf scripts to support
> multiple builds against the same source, as in
> 
>    mkdir build_dir1
>    cd build_dir1
>    ../configure
> 
> In the middle of this large autoconf based project
> there's a third party module that does not use autoconf.
> "./configure" style builds work because make just finds
> the stock Makefile in the source directory.  "../configure"
> style builds break because autoconf didn't create a
> directory and Makefile in the $(top_builddir) tree.
> 
> Is there a standard way to work around this other than
> adding Makefile.am's to the third party module?
> 
> I imagine that the workaround would involve copying the
> entire source module to the $(top_builddir) tree...
> 

hhmmm, there might be a real answer, and a real answer
for autoconf and automake, but I am just asking myself.

If you do a build with a normal Makefile and thereby
having builddir != sourcedir, then you surely must have 
some VPATH feature enabled. The automake files will do 
that too but they are able simulate it as the vpath
feature is not available in make `make`s (and more
often available but broken).

Now that's the point - if you use a make that has a
good vpath, and the plain Makefile has it enabled,
then you could just copy that Makefile to the
builddir, and if vpath is not available, you need
to copy all sources (or symlink it, as it is done
in some projects I know of).

Now... how the hl should autoconf know about those
parts of vpath-enbled make and vpath-using subdir?
Perhaps that's part of the problem it is left out
for now, although there are people with historic
mind about autoconf/automake who might be able to
say more...