On 16 July 2017 at 01:07, Nathaniel Smith <n...@pobox.com> wrote: > ...so this is where we diverge. As far as I understand it -- and I'm > pretty sure this matches all the major build systems like automake, > cmake, etc. -- the *only* difference between an in-place and > out-of-place build is where they cache the intermediate artifacts.
Out-of-tree builds also change the location of the final output artifacts (executables, shared libraries, etc), not just the intermediate ones - that's why you can run them even when the source code is on a read-only file system, and why several build systems call them "variant" directories these days rather than "build" directories. > So > if a build system is, say, scanning the source tree looking for stuff > to build... well, the source tree is the same either way, so if > they're going to pick up random junk in one case, they'll do it in the > other case as well. In fact I think they'd consider it a bug if they > didn't. Or contrariwise, if a build system is smart enough to > recognize that some files are junk and some are not, then it doesn't > matter where it's putting the intermediate files, it'll generate good > results either way. Full-fledged build systems aren't a problem for the clutter case, as they're not copying arbitrary files around, they're tracing their build dependency graph backwards from the desired outputs. So the single biggest long term contribution that PEP 517 makes to solving that problem is to enable newcomers to Python to start using backends that aren't as inherently error prone in this regard as setuptools and distutils are. However, the clutter problem still exists for any "grab files from disk and shove them into an archive" backends, like the naive "copy everything except hidden and special files into the sdist" and "copy the entire src directory into the wheel" example backend that we define in the PEP. For those, the best we can hope for in the general case is to say "at least try to keep the clutter in your sdists and wheel archives *consistent*". Anything beyond that will be up to the collective decision making of Python's userbase, as folks decide which backends they actually want to use for their projects. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
