Cannot build Macports in path containing spaces

[cowwoc@…]

1. Download Macports source tarball into a path containing spaces
2. Configure the environment and run make
3. The build will fail with numerous errors. For example:

checking that any existing MacPorts install can be upgraded... ./configure: line 10002: test: /Users/gili/.jenkins/workspace/GStreamer: binary operator expected
yes
./configure: eval: line 10011: syntax error near unexpected token `('
./configure: eval: line 10011: `prefix_expanded=/Users/gili/.jenkins/workspace/GStreamer (iOS)/client/ios/gstreamer/gstreamer/intermediate/macports'

or

===> making install in doc
/usr/bin/install -c -d -o gili -g staff -m 0755 /Users/gili/.jenkins/workspace/GStreamer (iOS)/client/ios/gstreamer/gstreamer/intermediate/macports
/bin/sh: -c: line 0: syntax error near unexpected token `('

[neverpanic (Clemens Lang)]

Please remember to use WikiFormatting when posting in trac.

[neverpanic (Clemens Lang)]

The problem with configure should be fixed in r97234 and r97235.

[cowwoc@…]

Cal,

Please note I mentioned two sample errors, but there are others. The best way to ensure that this issue is completely fixed is to try reproducing it on your end.

[neverpanic (Clemens Lang)]

r97239, r97243.

Since the fixes are simple, please consider providing a patch.

[ryandesign (Ryan Carsten Schmidt)]

Even if you can fix MacPorts itself to install in a path with spaces, likely many ports will fail to build in such a configuration. Years ago I reported this problem to the developers of autoconf, a configuration system used by many many ports, and the developers of autoconf said they had no plans to fix this issue and that it was a user error to attempt to use a path containing spaces. Therefore it seems unwise for us to attempt to support such a configuration either.

Consequently, because we've been under the impression that we'll never run in a path with spaces, many many portfiles make that assumption as well. It would be a great deal of effort to fix this problem in all portfiles, for no discernible gain, since it's trivial for the user to choose to install MacPorts a different path that doesn't contain spaces.

I would suggest closing this ticket as "wontfix".

[cowwoc@…]

Ryan,

Many users name their boot volume something with a space in it. Telling them to use a different path isn't a simple matter. Besides, I'm really irked by how often people try to sweep this kind of bug under the rug. There is no denying this is a bug. It's quite easy to fix, it just shows up in more places.

This bug report is specific to building MacPorts. If I have problems with a specific port I will file a separate bug report for it in the future. The number of ports I plan on using will be small, and I will try to submit patches whenever I can, so don't worry :)

[ryandesign (Ryan Carsten Schmidt)]

Replying to cowwoc@…:

Many users name their boot volume something with a space in it. Telling them to use a different path isn't a simple matter.

The boot volume is referred to as "/"; it does not matter what you name it.

Besides, I'm really irked by how often people try to sweep this kind of bug under the rug. There is no denying this is a bug. It's quite easy to fix, it just shows up in more places.

I understand your frustration, but MacPorts is not in a position to alter the thinking of the entire UNIX software industry; we can only provide a system for installing software packages, but that system is under the constraints of the software packages we offer. And I've already explained the very easy workaround you can employ: install to a path that does not contain spaces. This does not require any engineering resources on our part, so it is the solution I prefer.

This bug report is specific to building MacPorts. If I have problems with a specific port I will file a separate bug report for it in the future. The number of ports I plan on using will be small, and I will try to submit patches whenever I can, so don't worry :)

I do worry about expending effort to solve part of a problem, when I'm sure that solving the complete problem is impractical and time spent solving part of the problem will take time away from more useful fixes that would benefit more people.

[cowwoc@…]

Ryan,

I appreciate the candor of your reply. I'll tell you what I'll do... if I find a problem with a Makefile of a package, I will try to report it to the original (Linux) committers. Hopefully they will fix it under Linux and in the process it'll also get fixed under Mac. I will only report issues to you if the problem is specific to your port (in practice, I doubt this will ever occur).

[ryandesign (Ryan Carsten Schmidt)]

There are probably hundreds or thousands of Portfiles in which we use the variable ${prefix} (or ${worksrcpath} or ${destroot} or ${filespath} or ${distpath}, whose values begins with ${prefix}) in a shell command in a portfile without quoting it because we assume the prefix doesn't contain a space. Just looking at this very common construct which would fail if worksrcpath contained a space:

system "cd ${worksrcpath} && ..."

Using grep over our ports collection, I count over 300 ports doing that. This particular space-in-path problem has a simple solution: this code should be changed to:

system -W ${worksrcpath} "..."

but while changing "cd" to "-W" could be done with a simple search and replace, other situations would have to be examined on a case-by-case basis. You'd probably have to look at every "system" invocation; I count over 2600 "system" calls in our portfiles today.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #36359.