Re: contrib vs. gborg/pgfoundry for replication solutions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: contrib vs. gborg/pgfoundry for replication solutions
Дата
Msg-id 15912.1082693387@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: contrib vs. gborg/pgfoundry for replication solutions  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: contrib vs. gborg/pgfoundry for replication solutions  (Jan Wieck <JanWieck@Yahoo.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: What can we learn from MySQL?
Следующее
От: Shachar Shemesh
Дата:
Сообщение: Re: License question