-On [20101005 16:21], Barry Warsaw (ba...@python.org) wrote:
>Do any BSD distros provide multiple different builds of Python to their users?
For all I can tell, no. Assuming you are referring to different builds of
the same version.
>How do they handle having a debug build or non-debug build?
In
On Oct 05, 2010, at 10:50 AM, Jeroen Ruigrok van der Werven wrote:
>Also, from FreeBSD's ldconfig manual page:
>
>"Filenames must conform to the lib*.so.[0-9] pattern in order to be
>added to the hints file."
>
>So ending a shared object with the build flags will cause problems on
>FreeBSD and pro
On Oct 05, 2010, at 10:45 AM, Jeroen Ruigrok van der Werven wrote:
>-On [20101004 20:48], Barry Warsaw (ba...@python.org) wrote:
>>On Oct 02, 2010, at 01:40 PM, Antoine Pitrou wrote:
>>
>>>Besides, mingling different installations together makes uninstalling
>>>much more difficult.
>>
>>Not for a
On Oct 04, 2010, at 10:18 PM, Antoine Pitrou wrote:
>What is the point of shipping a different unicode representation? Is
>there any practical use case? I could understand a motivated user
>trying different build flags for the purpose of experimentation and
>personal enlightenment, but a Linux dis
-On [20101004 20:48], Barry Warsaw (ba...@python.org) wrote:
>On Oct 02, 2010, at 01:40 PM, Antoine Pitrou wrote:
>
>>Besides, mingling different installations together makes uninstalling
>>much more difficult.
>
>Not for a distro I think.
It does. On BSD the ports and packages are referred to a s
-On [20101004 22:03], Barry Warsaw (ba...@python.org) wrote:
>We already have libpython3.2.so.1.0 which also doesn't end in .so. I suppose
>we could put the build flags before the .so. part, but I think Matthias had a
>problem with that (I don't remember the details).
Using major and minor number
On Mon, 4 Oct 2010 16:01:17 -0400
Barry Warsaw wrote:
> >
> >Why would a distro want to provide all combinations of Python builds?
>
> Maybe not all, but definitely several. At least a normal build and a debug
> build, but a wide unicode build possibly also.
What is the point of shipping a diff
On Oct 04, 2010, at 09:10 PM, Antoine Pitrou wrote:
>On Mon, 4 Oct 2010 14:41:11 -0400
>Barry Warsaw wrote:
>>
>> For a distro, all those Python binaries have to go in /usr/bin. We
>> already symlink /usr/bin/python to pythonX.Y so I don't see the harm
>> in a few extra symlinks.
>
>Why would a
On Mon, 4 Oct 2010 14:41:11 -0400
Barry Warsaw wrote:
>
> For a distro, all those Python binaries have to go in /usr/bin. We already
> symlink /usr/bin/python to pythonX.Y so I don't see the harm in a few extra
> symlinks.
Why would a distro want to provide all combinations of Python builds?
O
On Oct 01, 2010, at 07:36 PM, Benjamin Peterson wrote:
>2010/10/1 Barry Warsaw :
>> I can think of a couple of ways out, none of which are totally
>> satisfying. Probably the easiest out is to change the PEP 3149
>> naming so that the files don't end in ".so". E.g. use this instead:
>>
>> foo.
On Oct 02, 2010, at 01:40 PM, Antoine Pitrou wrote:
>Besides, mingling different installations together makes uninstalling
>much more difficult.
Not for a distro I think.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Pyt
On Oct 02, 2010, at 09:44 AM, Martin v. Löwis 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
>>>
>
On Oct 02, 2010, at 04:50 PM, Nick Coghlan wrote:
>On Sat, Oct 2, 2010 at 10:24 AM, Antoine Pitrou
>wrote:
>> On Fri, 1 Oct 2010 20:06:57 -0400
>> Barry Warsaw wrote:
>>>
>>> With my branch, you'll end up with this in /tmp/python:
>>>
>>> bin/python3.2m - the normal build binary
>>> bi
On Oct 02, 2010, at 10:36 AM, Georg Brandl wrote:
>Am 02.10.2010 00:06, schrieb Barry Warsaw:
>
>> The reason is that the import.c logic that uses the struct filedescr
>> tables built from _PyImport_DynLoadFiletab are just not smart enough
>> to handle this case. All it knows about are suffix, an
On Sat, 02 Oct 2010 09:44:16 +0200
"Martin v. Löwis" wrote:
>
> I could accept that a suffix is parameter to configure (or some such),
> and then gets used throughout. By default, Python will not add a suffix.
> However, I still wonder why people couldn't just install Python in a
> different pref
Am 02.10.2010 00:06, schrieb Barry Warsaw:
> Let's say I build the foo module, which has an _foo extension for both the
> 3.2m and 3.2dmu builds. Everything gets installed correctly, and you'll see:
>
> lib/python3.2/site-packages/foo-...egg/_foo.cpython-32m.so
> lib/python3.2/site-packa
>>> 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?
>
On Sat, Oct 2, 2010 at 10:24 AM, Antoine Pitrou wrote:
> On Fri, 1 Oct 2010 20:06:57 -0400
> Barry Warsaw 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/py
On Sat, Oct 2, 2010 at 10:36 AM, Benjamin Peterson wrote:
> 2010/10/1 Barry Warsaw :
>> I can think of a couple of ways out, none of which are totally satisfying.
>> Probably the easiest out is to change the PEP 3149 naming so that the files
>> don't end in ".so". E.g. use this instead:
>>
>>
2010/10/1 Barry Warsaw :
> I can think of a couple of ways out, none of which are totally satisfying.
> Probably the easiest out is to change the PEP 3149 naming so that the files
> don't end in ".so". E.g. use this instead:
>
> foo.cpython-32dmu-so
> foo.cpython-32m-so
-1 Doesn't that brea
On Oct 02, 2010, at 02:24 AM, Antoine Pitrou wrote:
>On Fri, 1 Oct 2010 20:06:57 -0400
>Barry Warsaw 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/pytho
On Fri, 1 Oct 2010 20:06:57 -0400
Barry Warsaw 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 w
I am continuing my quest to be able to install multiple versions and builds of
Python simultaneously, so that they all nicely coexist. E.g. you could have a
"normal" build of Python 3.2 and a --with-wide-unicode --with-pydebug build
both installed and all packages with extensions would get built a
23 matches
Mail list logo
