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