From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_regress breaks on msys |
Date: | 2006-07-19 19:10:54 |
Message-ID: | 15139.1153336254@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Marc Munro | 2006-07-19 19:27:57 | Re: Index corruption |
Previous Message | Ron Mayer | 2006-07-19 18:55:33 | Re: plPHP and plRuby |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2006-07-19 19:33:36 | Re: pg_regress breaks on msys |
Previous Message | Bort, Paul | 2006-07-19 18:52:58 | Re: pg_regress breaks on msys |