develooper Front page | perl.perl5.porters | Postings from September 2016

[perl #129229] [PATCH] Fix Parallel Building

Thread Previous | Thread Next
From:
Father Chrysostomos via RT
Date:
September 20, 2016 16:50
Subject:
[perl #129229] [PATCH] Fix Parallel Building
Message ID:
rt-4.0.24-28237-1474390245-61.129229-15-0@perl.org
On Tue Sep 20 07:26:04 2016, demerphq wrote:
> On 20 Sep 2016 3:43 a.m., "Father Chrysostomos via RT" <
> perlbug-followup@perl.org> wrote:
> >
> > On Tue Sep 20 00:40:13 2016, sprout wrote:
> > > On Tue Sep 20 00:36:46 2016, sprout wrote:
> > > > What I want to know is why the build is trying to sort MANIFEST at
> > > > all.  Ideally, ‘make’ should *never* touch checked-in files, because
> > > > then ‘make distclean’ doesn’t work.  You can’t get a clean slate
> > > > unless you are using a git repository.
> > >
> > > Does the attached diff also fix the problem?  (Instead of working
> > > around the problem, it removes the cause.)
> >
> > Digging a little further, I see this commit:
> >
> > commit 19bf1007743b4337230ad3a4538df4bd94311fc4
> > Author: Yves Orton <demerphq@gmail.com>
> > Date:   Thu Dec 25 15:44:14 2014 +0100
> >
> >     automatically sort the MANIFEST if necessary
> >
> >     Instead of harrasing people to sort the manifest in our
> >     tests, we can just automatically sort the manifest when it
> >     changes.
> >
> >     That way the tests are actually testing that the auto-sort
> >     worked, and not that our devs put the new file in the right
> >     place.
> >
> > The problem with automatically sorting the MANIFEST is what I mentioned
> above: ‘make’ should not make changes to files tracked by git.  I think
> that commit was ill-advised.
> 
> I think we have to differ on that one.  The only way a patch ends up
> upstream in an incorrect order is if someone made changes to it and never
> ran make at all. Thus the scenario you describe would never occur on an
> unmatched perl.

1. Make changes
2. git commit
3. make test
4. All tests pass, so push.

I follow that routine routinely.  If I get ‘Can’t rebase because you have unstaged changes’ when I *know* I have committed, I am going to get very frustrated. :-)

> 
> And I don't agree about your make clean argument either in your other post
> .  Make clean does not undo changes to source code. The only way you end up
> in the scenario you describe as undesirable is when you have made changes
> to files in the first place

But what if I haven’t made any changes, but simply tried to build perl?

> and make clean is not intended to undo such
> changes.
> 
> That make might correct an innocuous error you made in a source file while
> making changes seems quite reasonable to me.
> 
> Anyway my view is that if we routinely test for something that can be fixed
> with a make command then make should just do that command automatically

No, instead of doing that command automatically, have a ‘make porting’ target that gets the tests passing, so that the hacker has more control over when things get run.  For non-critical things like manifest sorting, we can remove the tests and have ‘make porting’ as a standard thing to run when making a release.

(If people want to run ‘make porting’ from time to time themselves, they can.)

> and
> save a lot of fuss. (all things being equal etc)

I hope my suggestions will do the same, but without causing problems.

-- 

Father Chrysostomos


---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=129229

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About