Обсуждение: Making pgxs builds work with a relocated installation
I looked at the recently noted problem that pgxs builds only work if the installation paths recorded in Makefile.global are accurate; which pretty much breaks our claim to supporting relocatable installations. What I propose we do about this is change the path setup section of Makefile.global to look like (for each path variable) ifdef PGXS pkglibdir = $(shell pg_config --pkglibdir) else # existing code to set up pkglibdir endif Since a pgxs build has already assumed it could use pg_config to find pgxs.mk, this isn't introducing any new dependency, and it will allow the existing relocatable-path code to do its thing. Not all of the path variables set up in Makefile.global are currently available from pg_config; the missing ones are prefix exec_prefix sbindir mandir localedir libexecdir datadir sysconfdir pkgincludedir docdir The first three of these don't seem to be directly referenced anywhere in the Makefiles, so I propose just removing them from Makefile.global. The other ones will need to be added to pg_config's repertoire, unless someone can make a pretty good case that no pgxs-using module would ever need to install into that directory. Also note that I'm assuming the following path variables can continue to be defined as they are, ie, relative to other path variables that will get the pg_config treatment: includedir_server = $(pkgincludedir)/server includedir_internal = $(pkgincludedir)/internal pgxsdir = $(pkglibdir)/pgxs Comments? The other open issue in this area was that on Windows, pg_config needs to return space-free path names to avoid breaking the makefiles. It was suggested that this could be handled by passing pg_config's result path names through GetShortPathName() on that platform. That sounds OK to me but I'm not in a position to write or test such a patch; can someone take care of that? regards, tom lane
> -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane > Sent: 27 September 2005 01:13 > To: Peter Eisentraut > Cc: pgsql-hackers@postgresql.org > Subject: [HACKERS] Making pgxs builds work with a relocated > installation > > The other open issue in this area was that on Windows, pg_config needs > to return space-free path names to avoid breaking the > makefiles. It was > suggested that this could be handled by passing pg_config's > result path > names through GetShortPathName() on that platform. That > sounds OK to me > but I'm not in a position to write or test such a patch; can someone > take care of that? At the risk of getting squished in the rush to help, if noone else volunteers I'll try to find some time. :-) /D
> > The other open issue in this area was that on Windows, > pg_config needs > > to return space-free path names to avoid breaking the > makefiles. It > > was suggested that this could be handled by passing > pg_config's result > > path names through GetShortPathName() on that platform. > That sounds > > OK to me but I'm not in a position to write or test such a > patch; can > > someone take care of that? > > At the risk of getting squished in the rush to help, if noone > else volunteers I'll try to find some time. Missed this one when it came through the first time. Note: Not volunteering, just commenting on the how-fix :P Using GetShortPathName() will break on any system that has disabled short filename generatino, which IIRC is a recommended best practice both for performance and for security in legacy apps. I don't know what it does, but probably it will just return the same long path again. //Magnus
> -----Original Message----- > From: Magnus Hagander [mailto:mha@sollentuna.net] > Sent: 27 September 2005 08:58 > To: Dave Page; Tom Lane; Peter Eisentraut > Cc: pgsql-hackers@postgresql.org > Subject: RE: [HACKERS] Making pgxs builds work with a > relocated installation > > > > The other open issue in this area was that on Windows, > > pg_config needs > > > to return space-free path names to avoid breaking the > > makefiles. It > > > was suggested that this could be handled by passing > > pg_config's result > > > path names through GetShortPathName() on that platform. > > That sounds > > > OK to me but I'm not in a position to write or test such a > > patch; can > > > someone take care of that? > > > > At the risk of getting squished in the rush to help, if noone > > else volunteers I'll try to find some time. > > Missed this one when it came through the first time. Note: Not > volunteering, just commenting on the how-fix :P > > Using GetShortPathName() will break on any system that has disabled > short filename generatino, which IIRC is a recommended best practice > both for performance and for security in legacy apps. I don't > know what > it does, but probably it will just return the same long path again. If it's disabled, then they aren't going to be able to use short names anyway, therefore we can't do much about it. If you see what I mean! If GetShortPathName() just returns what was passed to it in such cases, then at least we won't be any worse off than we are now. Regards,Dave.
> > > > The other open issue in this area was that on Windows, > > > pg_config needs > > > > to return space-free path names to avoid breaking the > > > makefiles. It > > > > was suggested that this could be handled by passing > > > pg_config's result > > > > path names through GetShortPathName() on that platform. > > > That sounds > > > > OK to me but I'm not in a position to write or test such a > > > patch; can > > > > someone take care of that? > > > > > > At the risk of getting squished in the rush to help, if > noone else > > > volunteers I'll try to find some time. > > > > Missed this one when it came through the first time. Note: Not > > volunteering, just commenting on the how-fix :P > > > > Using GetShortPathName() will break on any system that has disabled > > short filename generatino, which IIRC is a recommended best > practice > > both for performance and for security in legacy apps. I don't know > > what it does, but probably it will just return the same long path > > again. > > If it's disabled, then they aren't going to be able to use > short names anyway, therefore we can't do much about it. If > you see what I mean! Well, are we sure thare are no other ways? Either some funky quoting or backslash-escaping spaces or something like that? > If GetShortPathName() just returns what was passed to it in > such cases, then at least we won't be any worse off than we are now. Right. That'll have to be checked though, the API docs don't seem to talk about that. Could be it gives you NULL or something equally evil.. //Magnus
> -----Original Message----- > From: Magnus Hagander [mailto:mha@sollentuna.net] > Sent: 27 September 2005 09:19 > To: Dave Page; Tom Lane; Peter Eisentraut > Cc: pgsql-hackers@postgresql.org > Subject: RE: [HACKERS] Making pgxs builds work with a > relocated installation > > > If it's disabled, then they aren't going to be able to use > > short names anyway, therefore we can't do much about it. If > > you see what I mean! > > Well, are we sure thare are no other ways? Either some funky > quoting or > backslash-escaping spaces or something like that? Tried quoting and '\ '. Neither work. > > If GetShortPathName() just returns what was passed to it in > > such cases, then at least we won't be any worse off than we are now. > > Right. That'll have to be checked though, the API docs don't seem to > talk about that. Could be it gives you NULL or something > equally evil.. Well, knowing you you have a VM setup in this way so testing should be easy enough :-p /D
Am Dienstag, 27. September 2005 02:12 schrieb Tom Lane: > What I propose we do about this is change the path setup section > of Makefile.global to look like (for each path variable) > > ifdef PGXS > pkglibdir = $(shell pg_config --pkglibdir) > else > # existing code to set up pkglibdir > endif That looks right. > Not all of the path variables set up in Makefile.global are currently > available from pg_config; the missing ones are > > prefix > exec_prefix > sbindir > mandir > localedir > libexecdir > datadir > sysconfdir > pkgincludedir > docdir > > The first three of these don't seem to be directly referenced anywhere > in the Makefiles, so I propose just removing them from Makefile.global. I see prefix := /usr/local/pgsql exec_prefix := ${prefix} bindir := ${exec_prefix}/bin sbindir := ${exec_prefix}/sbin in the default configuration, so we need to keep the first two at least. We don't need to expose them through pgxs, though. > The other ones will need to be added to pg_config's repertoire, unless > someone can make a pretty good case that no pgxs-using module would ever > need to install into that directory. pgxs only needs to expose the currently exposed variables plus sysconfdir, as previously discussed. Unless someone can make a case that they need to access the other directories. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut <peter_e@gmx.net> writes: > Am Dienstag, 27. September 2005 02:12 schrieb Tom Lane: >> Not all of the path variables set up in Makefile.global are currently >> available from pg_config; the missing ones are >> >> prefix >> exec_prefix >> sbindir >> mandir >> localedir >> libexecdir >> datadir >> sysconfdir >> pkgincludedir >> docdir >> >> The first three of these don't seem to be directly referenced anywhere >> in the Makefiles, so I propose just removing them from Makefile.global. > I see > > prefix := /usr/local/pgsql > exec_prefix := ${prefix} > > bindir := ${exec_prefix}/bin > sbindir := ${exec_prefix}/sbin > > in the default configuration, so we need to keep the first two at least. We > don't need to expose them through pgxs, though. I stand corrected on those. >> The other ones will need to be added to pg_config's repertoire, unless >> someone can make a pretty good case that no pgxs-using module would ever >> need to install into that directory. > pgxs only needs to expose the currently exposed variables plus sysconfdir, as > previously discussed. Unless someone can make a case that they need to > access the other directories. pgxs.mk itself requires access to datadir and docdir, so I don't see how you can maintain that those aren't necessary. The only reason it doesn't also reference mandir and localedir is that none of our current contrib modules have any man pages or locale support, but that hardly seems far-fetched as a requirement for external modules. Also, pkgincludedir *must* be supported else we cannot set up the -I options for includedir_server and includedir_internal. On second look, libexecdir isn't used anywhere, so we might as well just remove it entirely. But all the others seem necessary to me. regards, tom lane
Tom Lane wrote: > pgxs.mk itself requires access to datadir and docdir, so I don't > see how you can maintain that those aren't necessary. The only > reason it doesn't also reference mandir and localedir is that none of > our current contrib modules have any man pages or locale support, Well, I don't support the notion that pgxs installs things there by default, but if it does, then I guess we have to fix it to do so correctly. -- Peter Eisentraut http://developer.postgresql.org/~petere/
"Magnus Hagander" <mha@sollentuna.net> writes: > Using GetShortPathName() will break on any system that has disabled > short filename generatino, which IIRC is a recommended best practice > both for performance and for security in legacy apps. I don't know what > it does, but probably it will just return the same long path again. Yuck. Anyone have another idea on coping with space-containing pathnames? I suppose we could try to quote the path variables properly in all the makefiles, but that sure seems like a painful proposition. Meanwhile, I believe I've fixed the relocatability issue per se. regards, tom lane
Tom Lane wrote: > Yuck. Anyone have another idea on coping with space-containing > pathnames? Switch to scons. You heard it here first! -- Peter Eisentraut http://developer.postgresql.org/~petere/
> -----Original Message----- > From: Peter Eisentraut [mailto:peter_e@gmx.net] > Sent: 28 September 2005 06:37 > To: Tom Lane > Cc: Magnus Hagander; Dave Page; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Making pgxs builds work with a > relocated installation > > Tom Lane wrote: > > Yuck. Anyone have another idea on coping with space-containing > > pathnames? > > Switch to scons. You heard it here first! Oooh, that looks nice at first glance... /D
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: 27 September 2005 18:57 > To: Magnus Hagander > Cc: Dave Page; Peter Eisentraut; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Making pgxs builds work with a > relocated installation > > "Magnus Hagander" <mha@sollentuna.net> writes: > > Using GetShortPathName() will break on any system that has disabled > > short filename generatino, which IIRC is a recommended best practice > > both for performance and for security in legacy apps. I > don't know what > > it does, but probably it will just return the same long path again. > > Yuck. Anyone have another idea on coping with space-containing > pathnames? I suppose we could try to quote the path > variables properly > in all the makefiles, but that sure seems like a painful proposition. Actually it seems to work quite nicely - on Windows 2000 with short names disabled it generates paths like: C:\PROGRA~1\PostgreSQL\8.1-beta2\bin Ie, it still fixes the spaces, but leaves the long bits, umm, long. With short names enabled (on XP), you get: C:\PROGRA~1\POSTGR~1\827E4~1.1-B\bin Which is truly hideous, but works as expected in cmd.exe and Msys. Patch attached that does this, and doubles up on the backslashes to keep msys/make happy. Cmd.exe doesn't seem to care about the double backslashes. Regards, Dave
On Wed, Sep 28, 2005 at 10:05:48AM +0100, Dave Page wrote: > > Tom Lane wrote: > > > Yuck. Anyone have another idea on coping with space-containing > > > pathnames? > > > > Switch to scons. You heard it here first! > > Oooh, that looks nice at first glance... The only question is, do we want to force a Python dependency for building Postgres? I doubt it will be less portable than what we have now, but it will be extra burden for the users. Scons certainly seems nice anyway ... -- Alvaro Herrera http://www.advogato.org/person/alvherre "El destino baraja y nosotros jugamos" (A. Schopenhauer)
Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > The only question is, do we want to force a Python dependency for > building Postgres? That's not happening. Especially not now that Dave found the other solution does work ... regards, tom lane