Peter Eisentraut wrote:
> Claudio Natoli wrote:
> > 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.
>
> If that is your intention then your original proposal was
> wrong to begin with, because it resolves the locations even before build
time.
Huh? I guess it could be seen like that, as the subdirectory component is
fixed.
But from a win32/installer POV the only dir that matters IMHO is the install
root dir, which certainly is not fixed before build time in the original
proposal. I suspect we are talking at cross-purposes, because that seems
like exactly what you were asking for in the second paragraph here:
http://archives.postgresql.org/pgsql-hackers/2004-05/msg00064.php
Got an alternative run-time/win32-install-time solution to offer?
Cheers,
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>
