Re: Fixed directory locations in installs

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Fixed directory locations in installs
Дата
Msg-id 200405031431.i43EVvo23083@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: Fixed directory locations in installs  ("Andrew Dunstan" <andrew@dunslane.net>)
Ответы Re: Fixed directory locations in installs
Список pgsql-hackers
Andrew Dunstan wrote:
> Claudio Natoli said:
> >
> >
> > Peter Eisentraut wrote:
> >> Claudio Natoli wrote:
> >> > I'm yet to see a convincing argument for why we can't adopt the
> >> > "binary-location/../share" approach as submitted late March. AFAICS,
> >> > it was rejected on the basis that it was not platform independent
> >> > (no arguments there) and that we could not rely on the ".."
> >> > approach.
> >>
> >> The only objection was that it hardcodes the layout already in the
> >> source, which gives us no flexibility at all to try out different
> >> installation layouts.  If you want to compute the relative paths from
> >> bindir to libdir etc. at build time based on actual configure
> >> options, then I see no problem with that.
> >
> > But we want to resolve the locations at run-time, not build or
> > configure time. For win32, I'm yet to see why this approach is
> > egregious.
> >
> > Do you have an alternative solution to propose?
> >
> 
> I hope we are at cross purposes here, or else Peter's suggestion won't
> fly - we need to be able to decouple some of these things from
> configure/build time and defer them to installation/runtime. Any other
> result will have us attracting curses from on high from the whole Windows
> community, and other binary packagers won't get what I understand some
> want.
> 
> How about if we have a configuration flag --enable-relocation which would
> require a fixed layout based on an indeterminate root. This would have the
> following effects:
> 
> . if prefix did not contain 'postgres' or 'pgsql' then 'postgresql' would
> be appended.
> . all *dir configure options would be forbidden - they would be based on
> the prefix as now, and since it would contain 'postgres' the simple layout
> we want would be used.
> . binaries would have a DEFINE which would mean they would know they
> should look for other binaries and shared files in locations which are
> fixed relative to their own location rather than in the hardcoded
> locations.

Rather than turn off configure options, we can easily make this work for
arbitary configure flags.

Everything on Win32 drives off of the directory of the binary, which we
can probe for at runtime.

If they use the configure defaults, /lib is ../lib relative to /bin.  If
they specify:
bin    /usr/local/pgsql/binlib    /usr/local/lib/pgsql

then lib is ../../lib/pgsql relative to bin.

It is easy to write a C function that will give us the relative path
from bin to any of the compiled in locations like /lib or /share, and we
can use that instead of an abolute path.

Not sure how we can do this for Unix except perhaps probe PATH.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Gavin Sherry
Дата:
Сообщение: Re: ANALYZE locks pg_listener in EXCLUSIVE for long time?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ERROR: heapgettup: failed ReadBuffer