Re: Fixed directory locations in installs

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