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