This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ned.deily
Recipients ned.deily, rzn8tr
Date 2011-09-14.02:24:54
SpamBayes Score 1.3383478e-08
Marked as misclassified No
Message-id <1315967095.71.0.111124278996.issue12956@psf.upfronthosting.co.za>
In-reply-to
Content
It turns out that supporting a framework path name that contains spaces (or other special characters) is a much more pervasive change that I had originally expected.  That's because the path specified by ./configure --enable-framework= also becomes the default for --prefix which is referenced directly (and indirectly via derived variables) throughout Makefile.pre.in and currently the Makefile does not handle installing a standard Unix-style build on any platform to prefix path that includes spaces, much less a Mac framework build.  That is the following will fail during the install phases:

    ./configure --prefix="/path/with space"
    make && make install

This needs to be addressed first, primarily by quote-protecting all uses of prefix and its derivatives in Makefile shell rules and then the uses of PYTHONFRAMEWORK* variables in the Makefile also need to be protected.  It should be fairly straightforward to find all such uses but there are many of them and changes would affect all platforms that use the Makefile to build and the many variants for each platform (i.e. --enable-shared, --enable-framework, etc) so proper testing would be a major effort.

While I'm sympathetic to supporting arbitrary path names, I'm not sure if it is worth the effort.  I'm going to leave this open for now but I don't plan to work on it myself in the near future.
History
Date User Action Args
2011-09-14 02:24:55ned.deilysetrecipients: + ned.deily, rzn8tr
2011-09-14 02:24:55ned.deilysetmessageid: <1315967095.71.0.111124278996.issue12956@psf.upfronthosting.co.za>
2011-09-14 02:24:55ned.deilylinkissue12956 messages
2011-09-14 02:24:54ned.deilycreate