Re: Couldn't make check - Mailing list pgsql-hackers-win32

From Andrew Dunstan
Subject Re: Couldn't make check
Date
Msg-id 4784.24.211.141.25.1084011489.squirrel@www.dunslane.net
Whole thread Raw
In response to Re: Couldn't make check  ("Dave Page" <dpage@vale-housing.co.uk>)
Responses Re: Couldn't make check
List 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



pgsql-hackers-win32 by date:

Previous
From: "Dave Page"
Date:
Subject: Re: Couldn't make check
Next
From: Claudio Natoli
Date:
Subject: Re: Couldn't make check