autoconf
[Top][All Lists]
Advanced

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

vpath / Re: ../configure question


From: Guido Draheim
Subject: vpath / Re: ../configure question
Date: Fri, 06 Sep 2002 10:35:47 +0200

Es schrieb 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).
correction: in many `make`s. 
(although gmake has set a standard and many many corporate 
environment use gmake as make today. In some respects, the
macro capabilities of gmake can replace automake to high degree).

> 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).
forgot: if you assume good vpath (in a corporate
controlled environment that is a valid assumption)
then you could have the copy-makefile-to-builddir
done by autoconf itself - just rename the Makefile 
to Makefile.in and include it into configure-output. 
autoconf makes a copy for trying to substitute
some at-vars where there are none - which still works.

> 
> 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...
('cause I don't quite remember extra macro hints to
 declare extra assumptions in this area and perhaps
 they are not intended to exist, or not just perhaps).




reply via email to

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