On 17 July 2017 at 18:29, Ralf Gommers <ralf.gomm...@gmail.com> wrote: > On Mon, Jul 17, 2017 at 7:50 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >> The minimal specification for in-place builds is "Whatever you would >> do to build a wheel file from an unpacked sdist". > > Eh no, in-place has nothing to do with building a wheel. Several people have > already pointed this out, you're mixing unrelated concepts and that's likely > due to you using a definition for in-place/out-of-place that's nonstandard.
I'm using in-place specifically to mean any given PEP 517 backend's equivalent of an unqualified "./setup.py build_wheel". For an autotools backend, that might ultimately mean something like "./configure && make python_wheel". It *doesn't* necessarily mean the equivalent of "./configure && make", because it wouldn't make sense to assume that a project's *default* build target for a full-fledged build system will be to make Python wheel files (fortunately, frontends won't need to take, since hiding those kinds of details will be up to backends). I'm using out-of-tree to mean (as a baseline) what Daniel suggested: any given backend's equivalent of "./setup.py build -b <build_directory> build_wheel" (e.g. variant directories in Scons). One additional config setting needed: the build/target directory This approach means that backends can implement build directory support without caring in the slightest about how Python frontends intend to use it, and without worrying overly much about the different kinds of source directory (VCS clone, unpacked VCS release tarball, unpacked sdist) except insofar as they'll need to be able to detect which of those they've been asked to build from if it matters to their build process (e.g. generating Cython files in the non-sdist cases). The non-standard semantic convention being proposed specifically as part of PEP 517 is then solely that for frontends like pip, if build_sdist fails, they should fall back to just asking the backend for an out-of-tree build, rather than doing anything more exotic (or Python-specific). This *won't* give them the general assurance of sdist consistency that actually building via the sdist will, but that's fine - the assumption is that a frontend that cares about that assurance will only be using this interface if the sdist build already failed, so full assurance clearly isn't possible in the current environment. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig