[Python-Dev] issue 9807 - a glitch in coexisting builds of different types (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sat Oct 2 08:50:28 CEST 2010

On Sat, Oct 2, 2010 at 10:24 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

On Fri, 1 Oct 2010 20:06:57 -0400 Barry Warsaw <barry at python.org> wrote:

With my branch, you'll end up with this in /tmp/python: bin/python3.2m   - the normal build binary bin/python3.2dmu - the wide+pydebug build binary bin/python3.2m-config bin/python3.2dmu-config Do users really want to see such idiosyncratic suffixes?

Ordinary users won't be building Python from source. Developers won't care so long as we clearly document the sundry suffixes and describe them in the README (or in a PEP, with a pointer from the README).

... lib/libpython3.2.so.1.0.m lib/libpython3.2.so.1.0.dmum Ditto here. This seems to break well-known conventions. If I look at /usr/lib{,64} on my machine, I can't see a single shared libary file that ends neither in ".so" nor ".so.".

Having some characters on the end to flag different kinds of custom build seems like it fits within the .so naming conventions I'm aware of, but I'm sure the *nix packaging folks will pipe up if Barry starts wandering too far afield in this area.

Before trying to find a solution to your problem, I think it would be nice to get a consensus that this is really a desired feature.

Having multiple parallel "altinstall" installations be genuinely non-interfering out of the box certainly seems like a desirable feature to me.

Cheers, Nick.

-- Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list