On 17 Jan, 2008, at 14:22, glyph at divmod.com wrote: > On 12:02 pm, ronaldoussoren at mac.com wrote: >> On 17 Jan, 2008, at 9:40, glyph at divmod.com wrote: >>> On 07:55 am, lists at cheimes.de wrote: > >> The framework build of Python definitly targets the upper layer of >> the OSX stack, not just the Unix core. This sometimes causes >> confusion, but mostly from developers wandering over from a Linux >> system that complain that OSX isn't Linux. > > The framework build targets both layers, as I understand it - and it > sounds like you're saying it too, since it's not "just" the UNIX > core. Solaris isn't Linux either, by the way. These conventions > hold across far more than one operating system :). I know, but somehow most people I run into that even know that there are more unix flavors than Linux also know that while all unices are simular they are not exactly the same. > >> Note that even Darwin is not Linux, there are several differences >> that cause problems for naive porters. Two of those: Darwin uses >> different binary formats for shared libraries and plugins; the >> darwin linker hardcodes the full path to shared libraries into >> executables (without a runtime search path). > > Distutils should take care of this distinction in Python's case, no? > Xxx's autotools generate a shared library, PyXxx's setup.py > generates a plugin (or "dylib", is that still what they're called > these days?). Distutils does take care of it, but that doesn't stop users from complaining that 'cc -shared' doesn't result in a workable python extension ;-). BTW. dylibs are shared libraries, there is no common suffix for bundles. Python uses '.so' for its bundle, adding to the confusion for folks used to systems using ELF libraries ;-) > >>> An example: Let's say you have a GNU autotools project in C, which >>> we'll >>> call "Xxx", and a set of Python bindings, PyXxx. Combinator deals >>> with >>> this by using ~/.local, and providing scripts to set up PATH and >>> LD_LIBRARY_PATH to point to ~/.local/bin and ~/.local/lib, >>> respectively. >> >> ~/Library/Combinator would be a better installation root on OSX, >> that location fits better into guidelines from Apple and also >> avoids completely hiding the Combinator data from the user. > > I disagree, but Combinator's a complex beast and has a lot of other > moving parts which need to live in specific places. Its main > purpose is to manage your import path to easily switch between > different development branches of multiple projects, and so most of > its data is already in locations that the user has specified. > > A key thing about ~/.local in this case is that it isn't specific to > Combinator. It's any per-user installed dependency libraries for > development purposes, not necessarily on Combinator-managed > projects, and not even necessarily Python projects. Ah, so ~/.local is "just" a per-user variation on /usr/local? I didn't even know of that convention before this thread started, I tend to use ~/local (without dot) instead. > >> Why? Just because users can't remember on which platform they are >> developing ;-)? That said, there's a libpython.a file in the >> framework build for basicly that reason: enough users complained >> about there not being a python library they could link to that it >> was easier to add a symlink then trying to educate everyone. > > The system installation of Python on the mac has a nod in this > direction as well. /usr/bin/python is also present, as is /usr/lib/ > pythonX.Yÿ0Cas symlinks between the two locations. >> You could teach Combinator about running configure scripts ;-). > > Better yet, perhaps somebody should teach configure about MacOS, and > about per-user installation ;). I value my life to much to even think about developing this feature for auto*. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available Url : http://mail.python.org/pipermail/python-dev/attachments/20080117/e6f94a44/attachment.bin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4