Issue 5818: Fix five small bugs in the bininstall and altbininstall pseudotargets (original) (raw)

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"?