"A.M. Kuchling" wrote:

I began writing the fabled fancy setup script described in PEP 229, and then realized there was duplication going on here. The code in setup.py would need to know what libraries, #defines, &c., are needed by each module in order to check if they're needed and set them. But if Modules/Setup can be used to override setup.py's behaviour, then much of this information would need to be in that file, too; the details of compiling a module are in two places.

Possibilities:

1) Setup contains fully-loaded module descriptions, and the setup script drops unneeded bits. For example, the socket module requires -lnsl on some platforms. The Setup file would contain "socket socketmodule.c -lnsl" on all platforms, and setup.py would check for an nsl library and only use if it's there.

This seems dodgy to me; what if -ldbm is needed on one platform and -lndbm on another?

Can't distutils try both and then settle for the working combination ? [distutils isn't really ready for auto-configure yet, but Greg has already provided most of the needed functionality -- it's just not well integrated into the rest of the build process in version 1.0.1 ... BTW, where is Gerg ? I haven't heard from him in quite a while.]

2) Drop setup completely and just maintain setup.py, with some different overriding mechanism. This is more radical. Adding a new module is then not just a matter of editing a simple text file; you'd have to modify setup.py, making it more like maintaining an autoconf script.

Why not parse Setup and use it as input to distutils setup.py ?

Remember, the underlying goal of PEP 229 is to have the out-of-the-box Python installation you get from "./configure;make" contain many more useful modules; right now you wouldn't get zlib, syslog, resource, any of the DBM modules, PyExpat, &c. I'm not wedded to using Distutils to get that, but think that's the only practical way; witness the hackery required to get the DB module automatically compiled.

You can also wave your hands in the direction of packagers such as ActiveState or Red Hat, and say "let them make to compile everything". But this problem actually inconveniences *me*, since I always build Python myself and have to extensively edit Setup, so I'd like to fix the problem.

Thoughts?

Nice idea :-) -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

"A.M. Kuchling" wrote:

I began writing the fabled fancy setup script described in PEP 229, and then realized there was duplication going on here. The code in setup.py would need to know what libraries, #defines, &c., are needed by each module in order to check if they're needed and set them. But if Modules/Setup can be used to override setup.py's behaviour, then much of this information would need to be in that file, too; the details of compiling a module are in two places.

Possibilities:

1) Setup contains fully-loaded module descriptions, and the setup script drops unneeded bits. For example, the socket module requires -lnsl on some platforms. The Setup file would contain "socket socketmodule.c -lnsl" on all platforms, and setup.py would check for an nsl library and only use if it's there.

This seems dodgy to me; what if -ldbm is needed on one platform and -lndbm on another?

Can't distutils try both and then settle for the working combination ? [distutils isn't really ready for auto-configure yet, but Greg has already provided most of the needed functionality -- it's just not well integrated into the rest of the build process in version 1.0.1 ... BTW, where is Gerg ? I haven't heard from him in quite a while.]

2) Drop setup completely and just maintain setup.py, with some different overriding mechanism. This is more radical. Adding a new module is then not just a matter of editing a simple text file; you'd have to modify setup.py, making it more like maintaining an autoconf script.

Why not parse Setup and use it as input to distutils setup.py ?

Remember, the underlying goal of PEP 229 is to have the out-of-the-box Python installation you get from "./configure;make" contain many more useful modules; right now you wouldn't get zlib, syslog, resource, any of the DBM modules, PyExpat, &c. I'm not wedded to using Distutils to get that, but think that's the only practical way; witness the hackery required to get the DB module automatically compiled.

You can also wave your hands in the direction of packagers such as ActiveState or Red Hat, and say "let them make to compile everything". But this problem actually inconveniences *me*, since I always build Python myself and have to extensively edit Setup, so I'd like to fix the problem.

Thoughts?

Nice idea :-) -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/