Re: contrib vs. gborg/pgfoundry for replication solutions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: contrib vs. gborg/pgfoundry for replication solutions
Date
Msg-id 15912.1082693387@sss.pgh.pa.us
Whole thread Raw
In response to Re: contrib vs. gborg/pgfoundry for replication solutions  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: contrib vs. gborg/pgfoundry for replication solutions  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> What if we create a build/ directory as part of install that
> pg_config.h, Makefile.global, etc, anything a plugin would need, and
> install it by default.  Then, if we give folks an easy way to access
> them from their own apps and Makefiles, it would solve most of the
> problems.

No it wouldn't, because those files *do not work outside the build
tree*.  There are built-in assumptions about where the Makefiles
themselves live relative to the include tree, where the invoking module
is relative to all that, etc.  Certainly there are a couple of files we
need to install that we currently don't, but it's going to take some
actual work beyond that to fix the problem.  See for example
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=112244
and if you're interested try to fix it yourself; it didn't seem trivial
when I was poking at it.

The specific details aren't especially relevant to this thread, though.
What is relevant is that we agree to a commitment that we will make
it easy to build modules outside the current Postgres build environment,
and that we will have an ongoing commitment to make sure that that keeps
working.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: What can we learn from MySQL?
Next
From: Shachar Shemesh
Date:
Subject: Re: License question