From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Spaces in directory names |
Date: | 2005-12-23 16:39:46 |
Message-ID: | 200512231739.47400.peter_e@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
There are some TODO items about allowing spaces in directory names in various
places. I spent the connection-less time on the train today experimenting
with several scenarios. This is the status:
Installing into a directory containing spaces in names works as of a CVS head
a few weeks ago. This is done by quoting all the target names in the install
commands in the makefiles.
Building in-tree works no matter what the build directory is called. It don't
see a reason why this would not have worked.
Building out of tree currently does not work if either the source or the build
directory names contain spaces. An unfortunate source directory name already
makes configure fail because the directory names are not consistently
shell-quoted, so it's out of our reach. A build directory name with spaces
could be made to work with a small change in Makefile.global but will later
fail in the regression test directories because they do their own
calculations of abs_builddir with pwd. I haven't found a workaround for that
yet (which involves tricking make's vpath mechanism somehow) but if that
could be fixed then you could even do out of tree builds if the upper
directory path contains spaces in the names but your source directory suffix
doesn't if you refer to the source directory by a relative path. All in all,
this doesn't seem like a priority issue though. The average MacOS and
Windows population should be happy with the new current behavior.
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2005-12-23 16:41:49 | Re: [pgadmin-hackers] Client-side password encryption |
Previous Message | Dave Page | 2005-12-23 16:39:13 | Re: [pgadmin-hackers] Client-side password encryption |