<div dir="ltr">But you can remove Python/graminit.c and "make clean && make" works, right?</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 24, 2015 at 11:00 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><p dir="ltr"><br>
On 25 Jan 2015 01:09, "Benjamin Peterson" <<a href="mailto:benjamin@python.org" target="_blank">benjamin@python.org</a>> wrote:<br>
><br>
><br>
><br>
> On Sat, Jan 24, 2015, at 03:00, Nick Coghlan wrote:<br>
> > On 20 January 2015 at 10:53, Benjamin Peterson <<a href="mailto:benjamin@python.org" target="_blank">benjamin@python.org</a>><br>
> > wrote:<br>
> > ><br>
> > ><br>
> > > On Mon, Jan 19, 2015, at 19:40, Neil Girdhar wrote:<br>
> > >> I was also wondering why files like Python/graminit.c are in the<br>
> > >> respository?  They generate spurious merge conflicts.<br>
> > ><br>
> > > Convenience mostly.<br>
> ><br>
> > It also gets us a round a couple of bootstrapping problems, where<br>
> > generating some of those files requires a working Python interpreter,<br>
> > which you may not have if you just cloned the source tree or unpacked<br>
> > the tarball.<br>
><br>
> We could distribute the generated files in tarballs as part of the<br>
> release process.</p>
</div></div><p dir="ltr">It's far more developer friendly to aim to have builds from a source check-out "just work" if we can. That's pretty much where we are today (getting external dependencies for the optional parts on *nix can still be a bit fiddly - it may be worth maintaining instructions for at least apt and yum in the developer guide that cover that)</p>
<p dir="ltr">Cheers,<br>
Nick.<br>
</p>
</blockquote></div><br></div>