On Sat, Oct 2, 2010 at 10:24 AM, Antoine Pitrou <solip...@pitrou.net> wrote:
> On Fri, 1 Oct 2010 20:06:57 -0400
> Barry Warsaw <ba...@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.<some digits>".
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 | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
