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
|
Список | 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 по дате отправления: