Big +1 for passing the option to the backend rather than making the frontend figure out how to do each backend’s job for them.
And add MSBuild to the list, which trivially supports separate source, intermediate and output directories, as well as incremental rebuilds. (And recently got full x-plat support, so could potentially be useful on all platforms.)
Cheers,
Steve
Top-posted from my Windows phone
From: Nick Coghlan
Sent: Saturday, July 8, 2017 7:59
To: Nathaniel Smith
Cc: distutils-sig
Subject: Re: [Distutils] A possible refactor/streamlining of PEP 517
On 8 July 2017 at 13:36, Nathaniel Smith <njs@pobox.com> wrote:
> On Fri, Jul 7, 2017 at 6:23 AM, Daniel Holth <dholth@gmail.com> wrote:
>> FYI distutils supports out of tree builds too. It is the -b argument to
>> 'setup.py build'.
>
> In theory, yes, but in practice, there are lots of setup.py files out
> there that mutate the source directory. For example, every project
> using Cython.
>
> I don't think a distutils/setuptools backend could comply with
> Thomas's wording except by doing a copytree or sdist or something
> just-in-case.
Which is fine - the point of making it a parameter instead of a
separate hook is that the folks in the best position to know whether
or not a particular build system has native out-of-tree build support
are the developers of that particular PEP 517 backend.
Since we know Scons supports this natively (by way of the
"variant_dir" setting), I went and checked some of the other build
systems that folks may end up wanting to develop backends for.
Native build system support for out-of-tree builds, so developers of
these shims should be able to delegate handling "build_directory":
- Scons: set variant_dir appropriately
(http://scons.org/doc/production/HTML/scons-user.html#chap-separate)
- meson: *only* supports out-of-tree builds
(http://mesonbuild.com/Using-multiple-build-directories.html)
- waf: configure the output directory appropriately
(https://waf.io/book/#_custom_build_outputs)
- premake: set targetdir appropriately
(https://github.com/premake/premake-core/wiki/targetdir)
- CMake: simplest way seems to be to save the initial working
directory as the source directory, cd to the build directory, then run
"cmake <source_directory>"
- yotta; based on CMake, so same approach applies
- autotools/make: similar approach to CMake, but running
"<source_directory>/configure && make <target>" from the build
directory
- maven: require that projects using the shim support a configurable
build dir (https://stackoverflow.com/questions/13173063/out-of-tree-build-with-maven-is-it-possible/13173140#13173140)
- ant: also uses pom.xml files, so same approach as maven applies
- cargo: set CARGO_TARGET_DIR
(http://doc.crates.io/environment-variables.html#environment-variables-cargo-reads)
Explicitly willing to add native out-of-tree wheel creation based on
PEP 517's requirements:
- flit
Mostly assume in-place builds, no generic support for out-of-tree
builds that I can find, so developers of these shims will need to work
out how to handle "build_directory" (probably by copying the relevant
input files into the specified build directory and then doing an
in-place build, similar to the way Scons handles "variant_dir" by
default):
- setuptools/distutils
- gyp/ninja (including node-gyp)
- gradle
So I think the folks saying "We don't think a separate hook for build
directory preparation is the right abstraction" have a strong point,
as that approach doesn't appear to map cleanly to the design of *any*
popular build system for precompiled languages.
By contrast, "build_directory" as an optional setting for the binary
build command *does* map cleanly as a concept in many cases, and for
the ones where it doesn't, I readily found questions from other folks
also wanting to know how to do it, and PEP 517 interface shims copying
the files they care about then doing an in-place build is a perfectly
acceptable technical solution.
And as an added bonus, if a backend starts out by blindly doing
"shutil.copytree(source_directory)" for out-of-tree builds, then the
potential performance implications of that approach will become more
clearly a discussion between the projects using the backend and the
developers of the backend, rather than being something that frontends
like pip will need to worry about handling in the general case.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig