Re: Makefile.global is kind of a pain

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Makefile.global is kind of a pain
Date: 2000-06-22 23:02:38
Message-ID: 10726.961714958@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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/bar
ln -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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brook Milligan 2000-06-22 23:12:23 Re: NOTICES about portals
Previous Message Peter Eisentraut 2000-06-22 22:42:03 Re: problem with ALTER GROUP