[Distutils] Brewing controversy over header file installation

[Mark W. Alexander]

On Fri, 15 Sep 2000, Greg Ward wrote:
> On 15 September 2000, Mark W. Alexander said:
> > Since the python tree already contains stuff to do C modules, I 
> > don't see anything at all "wrong" with putting additional stuff
> > there for use by C developers. I'm just questioning whether it's
> > something that distutils should be responsible for. I think the
> > answer is a definite maybe. It seems like a lot of effort to
> > provide something that may not be a good fit.
> 
> Installing C headers is definitely something the Distutils has to do.
> Just as people write modules that depend on other modules, they also
> write extensions that depend on other extensions.  In C, that kind of
> dependence usually means two things: include a header file and link
> against a library.  In the specialized domain of writing Python
> extensions in C, I *think* all the header file is the only problem; the
> linking issue will be taken care of when both extensions are loaded into
> the Python interpreter.  (This is merely informed speculation; I've
> never actually written an extension that depends on facilities provided
> by another extension!  Things could well be different on platforms that
> don't follow the usual Unix model of shared libraries, where .so files
> can depend on each other, but the dependencies don't have to be resolved
> until load-time.)

Ok, I WAS taking my position for the sake of simplicity. Now I'm just
confused. Distutils installs headers, but not libraries, because a C module
developer may be making a module that requires another module. But, if
he's only got the headers of the required module, what does he link against?
If I follow what you're saying, you're suggesting that somehow this occurs
when python loads both modules. I don't think so. If the required module
has it's own headers, it follows that it must also have it's own library
which actually implements the functions defined in the headers. Python's
really good, but it can't resolve symbols that don't exist, so it needs
both libraries to resolve the dependencies. So, it doesn't make sense
to me to have headers without libraries.

The exceptions to this being the headers that provide the python
extension api. I just double checked, and on my system, those and
libpython are in the python-devel package. So even those are not
required on the typical user machine. Why would they need headers
for any other C mods they install?

> That's why the "install" command can install C header files (using the
> "install_headers" command).  We install .py and .so/.pyd files because
> they will be needed by Python programmers writing Python modules and
> applications; we install .h files because they might be needed by C
> programmers writing Python extensions.  We doesn't install any C
> libraries, either shared or static, because I have not yet seen a need
> for them.

I'm only providing opinions here, not code, so I'm very easily out-voted,
but I think distutils should do neither or both. I still feel that the
libraries are better provided by a generic (non-python) run-time package,
the headers (and usage docs) by a devel package, and the python
implementation by distutils. My bigest concern is that if distutils
starts doing the devel stuff, why shouldn't is do the run-time stuff
.....It's just a matter of time before distutils becomes the universal
build/install/package everything tool. I recommend you don't take that
first step.

If you're going to do headers, though, then you need to do the libraries
that implement them also. This would be a nice feature for developers
who want to share C modules, but I tend to think they would just
to tarballs or cvs.

Mark