Ned Deily <n...@acm.org> added the comment:
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.
----------
assignee: ned.deily ->
components: -Macintosh
priority: normal -> low
title: 2.7.2 build fails with --enable-framework and space in pathname on OS X
10.7.1 -> builds fail when installing to --prefix with space in path name
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12956>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
