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 BreamoreBoy, cosmicduck, loewis, ned.deily, terry.reedy
Date 2014-07-17.19:18:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1405624696.26.0.705046468495.issue18320@psf.upfronthosting.co.za>
In-reply-to
Content
"Also, how many variables would you want to protect from being changed? People may come up with ideas of changing arbitrary other Makefile variables, and guarding all of them is just not feasible."

I certainly wasn't contemplating guarding *all* of them.  I'm concerned about those that are documented and conventionally used in standard Makefiles, e.g. https://www.gnu.org/software/make/manual/make.html#Directory-Variables.  Of those, the only ones that appear to be overridable in the Python top-level Makefile are "prefix", "exec_prefix", and "datarootdir" (the latter does not seem to be used directly in the top-level Makefile but is used in ctypes libffi Makefile).  And "prefix" is the one that causes the problems.  If you really think someone is currently using this productively somehow, even with producing a broken Python, we could just issue a warning.  I just think we should not allow people to shoot themselves in the foot so easily without warning: when I do "make install", I expect everything to be installed under prefix, not partially under another prefix, and I expect subsequent installations using Distutils to work properly.
History
Date User Action Args
2014-07-17 19:18:16ned.deilysetrecipients: + ned.deily, loewis, terry.reedy, BreamoreBoy, cosmicduck
2014-07-17 19:18:16ned.deilysetmessageid: <1405624696.26.0.705046468495.issue18320@psf.upfronthosting.co.za>
2014-07-17 19:18:16ned.deilylinkissue18320 messages
2014-07-17 19:18:16ned.deilycreate