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> ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
