[Distutils] Beginnings of a C/C++ compiler interface

[Ovidiu Predescu]

On Mon, 12 Jul 1999 14:39:36 -0400 (EDT), "Fred L. Drake" 
<fdrake@cnri.reston.va.us> 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.


Greetings,
-- 
Ovidiu Predescu <ovidiu@cup.hp.com>
http://www.geocities.com/SiliconValley/Monitor/7464/