Re: [Distutils] macos support (weak?)
Recently, "Pete Shinners" <shredwheat@mediaone.net> said:
i've got some people doing MacOS testing for my extension package. currently support is great under windows and unix.
i was under the impression python2.1 shipped with some distutils code that was ready to go for macos? but from the reports i hear this is not the case?
Yes, it's in there. You need the distutils support with MacPython, though, some of the fixes needed for MacPython 2.1 did not make it to the CVS repository in time. But the one incorporated in the MacPython distirbution should work. But then: I'm the only one to ever have tested it, so..... :-)
the first problem is that it appears distutils does not find the default "site-packages" on its own?
It finds it for me. Hmm, idea: maybe the directory should exist, and it doesn't exist in the distribution? Ask your mac tester to create Python:Lib:site-packages and try again. If that's the problem I'll force site-packages to be created next time.
does mac have some sort of PYTHONHOME equivalent it can use to find its home? certainly there must be something because python can find all its own modules and packages. can distutils somehow tap into this knowledge to save the installer from entering the site-packages path when installing?
sys.prefix. And this is indeed what distutils uses, if I'm not mistaken.
the second problem is a little more serious. my project is using an external setup file to get all the extension compile flags. the library directories are being sent with "-Llibrary/path/lib" this works for windows and unix, but on macos it is creating absolute paths, not relative. so it looks like to get it working the user needs something like -Lmacintosh hd/libs, but the space is throwing things for a loop. does a backslash work before the space? anyways, when given a relative path it is becoming an absolute path
I never tried this, so I wouldn't know. For the things I tried I've never needed a library path (and it would actually be dangerous too) and I've always spelled out the filename paths to the specific libraries I use. But the thing to remember is that all the paths you use within distutils are URLs (even though they look very much like unix pathnames to the unsuspecting eye:-) so ../../bla should work even on a Mac, and you should be able to using %20 for space should work fine.
lastly, and most important of all, it looks like the libraries being passed in with "-l" are not even being sent through the XML to codewarrior.
Where are you passing the libraries with "-l"? In the linker switches? That is the wrong place, unless I'm mistaken. They should be in the "libraries" attribute. -L and -l are unixisms. Hmm, that is: unless the distutils infrastructure on Windows parses them to emulate their behaviour, in which case I guess it should do the same on the Mac. Can anyone shed a light on this?
anyways, my guess is that this is all related to using the external Setup file and loading it with read_setup_file(). is that not really been used for macos stuff? if sending proper Extension objects to the setup function is all thats needed then i can workaround this pretty easy.
You've lost me here. What's an external setup file? I asusme you don't mean the setup.py which is part of your package (and, thus, external to distutils) but something else? (the sofist answer would probably be "where is it documented?" :-)
has anyone had any luck building distutils extensions on macos when needing to link in extra libraries?
Yes, but I wouldn't be surprised if it was only your's truly:-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
Yes, it's in there. You need the distutils support with MacPython, though, some of the fixes needed for MacPython 2.1 did not make it to the CVS repository in time. But the one incorporated in the MacPython distirbution should work. But then: I'm the only one to ever have tested it, so..... :-)
hey jack, with more testing and some coding we seem to have gotten somewhere. i'll explain the results as i know them... (btw, this was all with macpython 2.1
the first problem is that it appears distutils does not find the default "site-packages" on its own?
It finds it for me. Hmm, idea: maybe the directory should exist, and it doesn't exist in the distribution? Ask your mac tester to create Python:Lib:site-packages and try again. If that's the problem I'll force site-packages to be created next time.
hmm, no followup info on this one, sorry
the second problem is a little more serious. my project is using an external setup file to get all the extension compile flags. the library directories are being sent with "-Llibrary/path/lib" this works for windows and unix, but on macos it is creating absolute paths, not relative.
I never tried this, so I wouldn't know. For the things I tried I've never needed a library path (and it would actually be dangerous too) and I've always spelled out the filename paths to the specific libraries I use.
ok, apparantly this was a one-liner fix in distutils. the include directories path was working fine, the library path was not working with relative paths. it sounds like metroworks treats include dirs and library dirs as the same thing. so one workaround was to just use all include dirs, but the one-line-fix has made things a little more consistent between platforms.
lastly, and most important of all, it looks like the libraries being passed in with "-l" are not even being sent through the XML to codewarrior.
Where are you passing the libraries with "-l"? In the linker switches? That is the wrong place, unless I'm mistaken. They should be in the "libraries" attribute. -L and -l are unixisms.
right, it turns out these were being properly bassed in as the libraries attribute. the guy doing the testing had to go into the XML outputter and apparantly add the library stuff in there. it didn't look like the library info was being passed through.
anyways, my guess is that this is all related to using the external Setup file and loading it with read_setup_file().
You've lost me here. What's an external setup file? I asusme you don't mean the setup.py which is part of your package (and, thus, external to distutils) but something else? (the sofist answer would probably be "where is it documented?" :-)
this was all wrong. later on we did some testing and the external setup file was definitely being parsed fine. the "read_setup_file" call in distutils reads in a Makefile-like textfile and turns it into a list of Extension objects. anyways, with a little digging we have got mac distutils working pretty well. we'll make sure the final code changes get back to you guys somehow.
participants (2)
-
Jack Jansen -
Pete Shinners