Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Brook MilliganDate: 2000-06-22 23:12:23
Subject: Re: NOTICES about portals
Previous:From: Peter EisentrautDate: 2000-06-22 22:42:03
Subject: Re: problem with ALTER GROUP

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group