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