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.