
<!DOCTYPE html>

<html>

<head>

<title></title>

</head>

<body><div>On Thu, Aug 24, 2017, at 06:20 PM, Daniel Holth wrote:<br></div>

<blockquote type="cite"><div dir="ltr"><div defang_data-gmailquote="yes"><div dir="ltr">On Thu, Aug 24, 2017 at 12:34 PM Thomas Kluyver <<a href="mailto:thomas@kluyver.me.uk">thomas@kluyver.me.uk</a>> wrote:<br></div>

<blockquote defang_data-gmailquote="yes" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><div><div>Is there a reason to ask for an 'unclean' build, though? There may be a performance optimisation from reusing cached data,<br></div>

</div>

</blockquote><div><div><br></div>

<div>For the same reason you would ever ask for incremental builds, to more quickly iterate while hacking, imagining that you are using the PEP 517 interface to develop, perhaps to have a uniform interface to patch something when you are not familiar with exactly the build system it uses.<br></div>

</div>

</div>

</div>

</blockquote><div><br></div>

<div>Yup, this is what I meant about using cached data for performance. But I don't think this requires builds to modify the source directory. The build system can cache data elsewhere on the filesystem, whether or not it's given an explicit build_directory.<br></div>

<div><br></div>

<div>I think we can specify one kind of build that is both 'clean' (doesn't modify the source directory) and incremental (can use cached data to speed up the build). If that's workable, it seems like it would save a lot of headaches rather than trying to specify them as two different options.<br></div>

<div><br></div>

<div>We have explicitly excluded editable installs (i.e. inplace builds) from this PEP, though we can add a hook for that in a later PEP. I agree with you that this PEP should allow for fast incremental (but non-inplace) builds if possible, though.<br></div>

<div><br></div>

<div>Thomas<br></div>

</body>

</html>