On Mar 27, 2014, at 3:42 PM, Daniel Holth
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. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA