Re: Couldn't make check

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Couldn't make check
Дата
Msg-id 4784.24.211.141.25.1084011489.squirrel@www.dunslane.net
обсуждение исходный текст
Ответ на Re: Couldn't make check  ("Dave Page" <dpage@vale-housing.co.uk>)
Ответы Re: Couldn't make check  ("Dave Page" <dpage@vale-housing.co.uk>)
Список 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 по дате отправления:

Предыдущее
От: "Dave Page"
Дата:
Сообщение: Re: Couldn't make check
Следующее
От: Claudio Natoli
Дата:
Сообщение: Re: Couldn't make check