On Mon, 12 Jul 1999 14:39:36 -0400 (EDT), "Fred L. Drake" firstname.lastname@example.org wrote:
Ovidiu Predescu writes:
The way I saw things happening with other free software packages is to provide already configured files for Windows and Mac OS. You simple don't run the configure tools at all but come up with some assumptions on those platforms.
For a finished, end-user package, this is true. Based on the developer's day discussion at IPC7, distutils will also be used to help the developers of those packages. Many authors are not able to provide binary distributions for all platforms. The ideal would be for me to put together a source distribution as a distutils-based package; people with access to various platforms can pull that down, build any platform-dependent components, and then create an installable package for others to use. Hopefully this can be reduced to one or two commands. There are also people who will want to build from sources regardless of platform; having a Python-only system makes this a lot easier; only the compiler issues become platform-dependent, and that can be isolated within the distutils package.
OK, I think I can understand that. What I'm saying is that there are two different things:
- a tool to help the compilation of C extensions
- a tool to install a binary package on a Python distribution
The distutils package could help both developers and packagers accomplish the second thing.
The autoconf package however helps both crowds deal with platform dependent issues. There are too many details we need to take care of that has already been taken care of in autoconf. There is a lot of work we need to put in figuring out all the things that autoconf solves, header files, libraries, behaviors of various function libraries and system calls. All these may be important for a C extension that does heavy use them.
In my mind a combination of these two tools is the best. Maybe a Python configure tool would have its merits, however I would take a pragmatic approach. I think we first need to focus on a packaging tool and then on a distribution site for Python packages (sort of CPAN) and then worry about the rest.
The output generated by autoconf, aka the configure script, is not covered by GPL, so there's no licensing issue here. Only the autoconf package itself is covered by GPL, but not its result.The autoconf manual also specifies this very
I agree. This issue is not entirely a matter of legal interpretation, unfortunately; some organizations will (reportedly; I don't know of any documented cases) fire people for installing un-approved software, and the GPL or GNU label can make corporate software managers very leery. Whether or not it should is *not* the issue.
I wouldn't worry about such people. I think these days there are less people that think like this. In the future, with big companies like HP, SGI, Sun and others actively supporting free software there will be even less people thinking like that.
Having the system entirely in Python also helps when creating packages on non-Unix systems; autoconf may not do the right thing on a Macintosh!
As I pointed out above, we are talking about two different things. The packaging is one thing while identifying system specific issues is a different one. I don't argue about building a Python packaging tool, I think this is a very good thing, just about the merits of creating a new tool for determining system specific things.