-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 numbers
-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 specific
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
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 distro I
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 probably
-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?
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, and for
On Oct 02, 2010, at 04:50 PM, Nick Coghlan wrote:
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
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
Do users really want to
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
On Oct 01, 2010, at 07:36 PM, Benjamin Peterson wrote:
2010/10/1 Barry Warsaw ba...@python.org:
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:
On Mon, 4 Oct 2010 14:41:11 -0400
Barry Warsaw ba...@python.org 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
On Oct 04, 2010, at 09:10 PM, Antoine Pitrou wrote:
On Mon, 4 Oct 2010 14:41:11 -0400
Barry Warsaw ba...@python.org 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
On Mon, 4 Oct 2010 16:01:17 -0400
Barry Warsaw ba...@python.org 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
On Sat, Oct 2, 2010 at 10:36 AM, Benjamin Peterson benja...@python.org wrote:
2010/10/1 Barry Warsaw ba...@python.org:
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.
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
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
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
On Sat, 02 Oct 2010 09:44:16 +0200
Martin v. Löwis mar...@v.loewis.de 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
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
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
On Oct 02, 2010, at 02:24 AM, Antoine Pitrou 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
2010/10/1 Barry Warsaw ba...@python.org:
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
23 matches
Mail list logo
