Re: pg_regress breaks on msys

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_regress breaks on msys
Дата
Msg-id 15139.1153336254@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_regress breaks on msys  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg_regress breaks on msys  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
I wrote:
> Ah-hah, so apparently "make install DESTDIR=foo" somehow inserts DESTDIR
> after that instead of before it?  What we need is a way to determine the
> paths that make install used ...

AFAICS, the makefiles are just blindly concatenating DESTDIR with bindir
etc, for instance this is how initdb/Makefile installs initdb:
$(INSTALL_PROGRAM) initdb$(X) '$(DESTDIR)$(bindir)/initdb$(X)'

The evidence at hand says that this should produce exactly the same path
string as pg_regress is then using to call initdb.  So the question in
my mind now is how come the "make install" step isn't failing.  For that
matter, this same path-construction technique was used by the
shellscript... so how come it worked before?

It would be simple enough to make pg_regress strip off a drive letter
from the path strings it receives from the Makefile, but I'm not seeing
a principled way to discover that the "/msys/1.0/" part has to go.  How
are the makefiles managing to generate a different value of $(bindir) at
install time than what was passed into pg_regress at build time?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ron Mayer
Дата:
Сообщение: Re: plPHP and plRuby
Следующее
От: Marc Munro
Дата:
Сообщение: Re: Index corruption