Repository navigation
Fix five small bugs in the bininstall and altbininstall pseudotargets #50068
Description
| BPO | 5818 |
|---|---|
| Nosy | @larryhastings, @benjaminp |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2009-04-25.21:04:55.722>
created_at = <Date 2009-04-23.06:28:33.387>
labels = ['build']
title = 'Fix five small bugs in the bininstall and altbininstall pseudotargets'
updated_at = <Date 2009-04-25.21:04:55.710>
user = 'https://github.com/larryhastings'bugs.python.org fields:
activity = <Date 2009-04-25.21:04:55.710>
actor = 'benjamin.peterson'
assignee = 'none'
closed = True
closed_date = <Date 2009-04-25.21:04:55.722>
closer = 'benjamin.peterson'
components = ['Build']
creation = <Date 2009-04-23.06:28:33.387>
creator = 'larry'
dependencies = []
files = ['13744']
hgrepos = []
issue_num = 5818
keywords = ['patch']
message_count = 3.0
messages = ['86350', '86351', '86552']
nosy_count = 2.0
nosy_names = ['larry', 'benjamin.peterson']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue5818'
versions = ['Python 3.1']
Activity
larryhastings commentedon Apr 23, 2009
Makefile.pre.in as checked in has several small bugs:
First, the altbininstall target runs "ln -s" without first ensuring the
destination doesn't exist. If you run "make install" twice, without
manually deleting $prefix/bin/python3 between the runs, the "ln" fails
and "make" aborts. This happens pretty early in the install process, so
for example this means you can't edit a module in Lib and re-install it.
Second, the bininstall target no longer installs a "python" executable.
It should hard-link "python" to "python3.1"--as indeed is the entire
point of having the bininstall target--but it doesn't. (I was quite
surprised by this. I would have asked the person who removed it--but
"svn blame" doesn't show you who *removed* a line, and I didn't have the
inclination to go bisecting to sleuth it out on my own.)
Third, when altbininstall and bininstall write the "python3.1" and
"python" executables in the prefix directory, they also create
corresponding "python3.1-config" and "python-config" configuration
reporting scripts. But altbininstall doesn't create a "python3-config"
to go with "python3".
Fourth, maninstall is only run as part of bininstall, not altbininstall.
This means that you only got the "python3.1" man page if you ran
bininstall, and we all know running bininstall is not recommended.
Fifth, bininstall and altbininstall don't properly honor $EXE; sometimes
they specify it and sometimes they don't. To be honest I'm not sure
this matters in the slightest. $EXE is only non-empty for Windows
builds, and Windows has a completely separate build process. And even
if you used the Makefile to build, I cannot imagine you using it to
install. Still, a foolish consistency is the hobgoblin of my little mind.
My patch fixes all of the above. While I was staring at it, I also
touched up some comments.
One final question: why do we use soft-links to "python3.1-config" but
hard links to "python3.1"?
larryhastings commentedon Apr 23, 2009
Minor correction for the "First" bug mentioned: altbininstall is running
"ln", not "ln -s".
benjaminp commentedon Apr 25, 2009
Thanks for the patch! Fixed in r71935.