Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> Awhile back I was complaining that configure was dumping its results
>> into too many files already.
> If you're saying that configure should ideally only substitute things into
> Makefile.global and nowhere else then we're never going to have separate
> build directories, unless you know something that I don't. Every
> subdirectory where you build anything at all needs to have a Makefile.in.
> (Hint: How else will the build tree be created? How will the build tree
> find the source tree?)
The separate-build-tree projects that I've used initialize the build
tree by doing, for each source directory containing C files (say,
src/foo/bar/)mkdir obj/foo/barln -s ../../../src/foo/bar/Makefile obj/foo/bar/Makefile
and then VPATH is set by the Makefile to ../../../src/foo/bar
(note this can be hard-wired in the Makefile, as long as it knows where
it lives in the source tree) and away you go. Of course files that
configure actually *needs* to make a modified copy of will go
right into the object tree. But you don't need to copy-and-edit
every Makefile just to get the VPATH info right.
This assumes that each object tree is a sibling of the src tree
(so you'd make .../pgsql/obj.linux, .../pgsql/obj.hpux, etc if you
are building for multiple architectures). If you need to build
somewhere else, a symlink or two can fake it.
> Yes, that will eventually make config.status run
> four times longer than it does now but that's the price to pay. If we
> don't want to do that then it'd be best that I know now.
I'd like to have the ability to have a separate build tree, but not at
the price of making configure run 4x longer --- especially not if it
runs 4x longer for everyone whether they want a separate build tree or
not. I think the villagers will be on your doorstep with pitchforks
if you try to push that through ;-). The nice thing about the above
approach is that if you aren't building in a separate tree, you don't
need to expend any work at all except on the files that really need
to be edited.
regards, tom lane