Peter Eisentraut wrote:
>Andrew Dunstan wrote:
>
>
>>Binaries can find other binaries the way they do now: look in our own
>>location, then in the path.
>>
>>
>
>No, we can't look into the path. We have no information that says that
>anything useful pertaining to our installation is in the path.
>
Well, assuming all the binaries are installed in one location our own
location should do the trick.
>
>
>
>>Other files could be found by looking in 1) as per commandline (e.g.
>>-L in initdb) 2) hardcoded location, 3) our-location/../share
>>
>>
>
>Nothing says that ../share contains anything useful. Maybe it's
>../share/pgsql, or maybe ../share/postgresql, or maybe
>../share/postgresql-7.4.2 or maybe it's elsewhere altogether because
>you have just moved your installation tree to make room for a new one.
>We can't take guesses like this based on "usual installations".
>
>The only hard facts that we can use are hardcoded/compiled-in locations
>and explicit information passed via command-line arguments or
>environment variables. None of this seems to be useful for Windows
>installations. As far as I recall, the Windows installation routines
>only ask you for one installation directory but not all the individual
>ones. If this is true, then we could hardcode relative paths, but
>maybe I'm mistaken. Can someone give a couple of full examples of
>typical Windows installation layouts?
>
>
>
The only one I can think is typical is all in one location, e.g. as if
you had specified --prefix="c:/foo/postgresql"
But there might be more exotic animals out there.
cheers
andrew
