On 27 September 2000, Pete Shinners said:

i've got a python extension that is simply a wrapping around another C library. (not an uncommon case :])

I take it you mean a C library that's already installed on the target system, not when you ship the source for.

i cannot figure out the 'right' way to check for and link/include this dependency into my distutils setup.py script.

under linux, it's pretty easy to assume the correct header and shared library will be somewhere in the standard include and library directories /usr/local/include, /usr/local/lib, etc

I think you're getting at auto-configuation here. There are some initial stabs at general, cross-platform auto-configuration in the Distutils, but they are unfinished and will remain so until after Distutils 1.0. (Bummer.)

my main concern is getting it working with windows (and keeping it crossplatform happy for linux). my best bet in windows seems to be walk around the parent directory tree trying to find directories for the dependency??

I think it's probably best to avoid trying to roll-your-own auto-configuration code. Well, maybe: if you do go this route, you will probably learn a lot about cross-platform auto-configuration, and maybe you can help out with the auto-configuration support for Distutils 1.1. The cheap and easy way to do this is: let the user worry about it. As of Distutils 0.9.3, there's a very nice way to let the user worry about -- include an old-fashioned Setup file! That's right, you can put something like this in your distribution: # uncomment this lines for Unix/Linux (possibly changing library dir) #foo foo.c -L/usr/lib -lfoo # or this one for Windows #foo foo.c -L"C:\Program Files\Foo" -lfoo (I'm assuming you're compiling foo.c to create the "foo" extension module, linking against in /usr/lib/libfoo.{a,so} or "C:\Program Files\Foo\foo.dll".) Of course, your README will have to tell users to edit the Setup file before building. This is icky, but it beats editing setup.py and will have to do until we have proper auto-configuration. Then, your setup script would do this: from distutils.extension import read_setup_file ... extensions = read_setup_file("Setup") if not extensions: sys.exit("you forgot to edit Setup!") setup(name = "foo", version = "1.0", ..., extensions = extensions) and away-you-go. Let me know how it works... this is pretty new code, and It Worked For Me (TM). This does tie you to Distutils 0.9.3, which of course ties you to Distutils 0.9.4 since 0.9.3 was broken (oops). Oh well, it keeps everyone in practice, constantly upgrading the Distutils. ;-) Greg -- Greg Ward gward@python.net http://starship.python.net/~gward/

Pete Shinners wrote: Just thought of something else that is probably cleaner. Add som command line options and have the user specify where the library and header files are.... Mike

i've got a python extension that is simply a wrapping around another C library. (not an uncommon case :])

i cannot figure out the 'right' way to check for and link/include this dependency into my distutils setup.py script.

under linux, it's pretty easy to assume the correct header and shared library will be somewhere in the standard include and library directories /usr/local/include, /usr/local/lib, etc

my main concern is getting it working with windows (and keeping it crossplatform happy for linux). my best bet in windows seems to be walk around the parent directory tree trying to find directories for the dependency?? if that is the best way, it would probably be nice for the linux version to use this method or look in the standard compiler directories ???????

i'm hoping someone out there has an example doing just this sort of stuff i could look at. the documentation doesn't mention anything about this sort of stuff. (except for adding library and include info to the Extensions() call

thanks for any help and/or guidance. the distutils have just amazed me.

(please help, i couldn't get any responses on c.l.python)

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://www.python.org/mailman/listinfo/distutils-sig

-- Mike Olson Principal Consultant mike.olson@fourthought.com (303)583-9900 x 102 Fourthought, Inc. http://Fourthought.com Software-engineering, knowledge-management, XML, CORBA, Linux, Python