Ovidiu Predescu wrote:
As I already wrote in a previous post, I don't argue about the utility of a Python packager tool but about how useful would be to work on a configuration tool right now.
Some of the extensions that I wrote use configure to check for header files and library versions. These things are very well done by autoconf, and my point is that we probably don't need another tool to do this. What we need though is standard way to integrate configure in the process of building a package. In a normal C package that uses configure, this is done by running configure and then make. The question is how configure could be integrated with the distutils setup.py script? How are the configure options passed to it and what is the order of execution, first configure and then setup.py? Just wondering if this is reasonable...
Well, you are certainly right in saying that autoconf already handles what I proposed in an earlier mail. OTOH, the distutils package is intended to be cross-platform and the autoconf output does not run on non-Unix platforms.
Given that the compiler interface provides an abstract interface to the compiler (+ the linker) and its installation, it only seems natural to use the interface to "try out some things" much like the generated configure scripts do.
I don't want to reinvent a wheel here: most config setups are very primitive and don't need the full-blown autoconf mechanisms. Some more methods on the compiler interface would enable this for those who want to use the feature, something like
which return 1/0 to state "success" / "failure" and implement proper cleanup of the intermediate files. Very simple, really no need to argue here, IMHO...