On Thu, Mar 27, 2014 at 7:48 PM, Donald Stufft donald@stufft.io wrote:
On Mar 27, 2014, at 3:42 PM, Daniel Holth dholth@gmail.com wrote:
I became convinced that build was an inherently arbitrary-code process, and not something to be universally handled by a declarative system, when I observed an autotools project under configuration. The things spend ten minutes writing and compiling snippets of C code to determine which features are and are not supported by the runtime. This is *very* arbitrary code and probably one of the tamer things people like to do during builds.
As usual I blame distutils, because the separation is not there. So when you blame setup.py for having to run procedural code to generate the *metadata* you might go to far and think you should also eliminate a procedural build - simply because build and metadata are not adequately separate in the distutils design. Declarative build systems are a nice idea but they are not going to work for everyone. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Well for the record auto tools does all of that because there’s near zero ability to introspect the compiler to figure out what it supports except by compiling little programs that depend on X feature and then running them to see if they work or not.
That being said, yes building code is inherently a process that needs to execute things and cannot be made completely static. I believe the metadata itself can be static, and instead of an arbitrary build script we can declare a build hook, but that’s an argument for a PEP!
I do believe a declarative build system can work for the 90% case though and should probably be the “default” option.
It is indeed possible for most python packages, and I tried to figure out quite a few things to make that percentage as high as possible in Bento.
The really difficult part is not that, though, but making the system pluggable to allow pretty much arbitrary extensibility. What makes distutils very ill suited to that task is the whole subcommand model where options are not known in advance (that was the #1 issue when integrating distutils and scons).
For bento, I came up with a system of 'build manifest', where each command produces a text-based 'protocol' that other commands might use ( https://github.com/pv/bento/blob/master/doc/source/hacking.rst). The implementation is not great but I think the idea is still sound: this means that in theory, you could build C extensions with something not involving python at all (e.g. make), but as long as the build process output that file, you could build installers from the system. IOW, the json file acts as 'middleware'.
What any future solution should *not* try to do is inventing yet another build system
David