From: | "Andrew Dunstan" <andrew(at)dunslane(dot)net> |
---|---|
To: | <pgsql-hackers-win32(at)postgresql(dot)org> |
Subject: | Re: Couldn't make check |
Date: | 2004-05-08 10:18:09 |
Message-ID: | 4784.24.211.141.25.1084011489.squirrel@www.dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers-win32 |
Dave Page said:
> It's rumoured that Andrew Dunstan once said:
>> Dave Page wrote:
>>
>>
>> Yes, but it's a hack - we need pg_regress to set up the path to the
>> temp install correctly, not to rely on having installed first.
>
> Modifying the pg_regress script isn't going to help for daily use of
> psql. and other apps that want to use libpq.dll. We need a more robust
> solution such as a mod to the system path, or, I know you can register
> .exe locations in the registry - dunno if you can do that for a dll as
> well.
But the question was not about daily use of pgsql. It was specifically
about running 'make check', for which we should *not* rely on existing
environment settings. What if we have version A installed and we want to
test version B? If we rely on existing PATH settings we'll pick up the
wrong DLLs.
On Unix pg_regress supplies a special LD_LIBRARY_PATH, to find the
temp_install libraries, on Cygwin it supplies a special PATH for the same
purpose. The correct fix for MINGW is a one line change to pg_regress.sh
to do the same thing in this respect as it does on cygwin.
For daily use I agree that we should also do something. One possibility is
to put the DLLs into the bin directory instead of into a separate lib
directory. IIRC, Windows executables always search their own location
first for wanted DLLs before searching the PATH. Alternatively, we could
have the installer modify the system path.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Claudio Natoli | 2004-05-08 10:34:09 | Re: Couldn't make check |
Previous Message | Dave Page | 2004-05-08 09:21:26 | Re: Couldn't make check |