Front page | perl.perl5.porters |
Postings from September 2016
Re: [perl #129229] [PATCH] Fix Parallel Building
Thread Previous
|
Thread Next
From:
demerphq
Date:
September 21, 2016 14:00
Subject:
Re: [perl #129229] [PATCH] Fix Parallel Building
Message ID:
CANgJU+WUcZEtXV0+RvrEZwP-p2c7mMg0BJo4pJMLNzG-UfBFAQ@mail.gmail.com
On 21 Sep 2016 09:53, "demerphq" <demerphq@gmail.com> wrote:
>
> On 20 Sep 2016 12:51, "Father Chrysostomos via RT" <
perlbug-followup@perl.org> wrote:
> >
> > 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. :-)
>
> Not as frustrated as I get when I make a change and it fails test because
of failing manifest.t
>
> I mean has it happened even once yet?
>
> Also personally I think committing before you run make test is a bit
optimistic. I mean it's like that line about the doctor... So don't do
that... ☺️
>
> > >
> > > 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?
>
> Lots of what ifs here, but have any of them happened?
>
> I mean basically you are saying I should be frustrated about something so
that you don't get frustrated while using an arguably broken workflow. Why
does your preference about something that hasn't happened trump my
preference (AFAIK shared with others)?
>
> Luckily there is an option where neither of us have to be frustrated. ☺️
>
> > > 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.)
>
> I am fully supportive of this option, and for more than just manifest.t
>
> > > and
> > > save a lot of fuss. (all things being equal etc)
> >
> > I hope my suggestions will do the same, but without causing problems.
>
> I do too.
By the way there is an option available that we did not discuss. We could
simply make the manifest sort contingent on being in a git repository with
uncommitted changes to MANIFEST.
That would make both of us happy right? In my workflow the test would not
annoy and I wouldn't have to worry about changes to MANIFEST, and in yours
tests would fail if you made an unsorted modification of the file.
Yves
Thread Previous
|
Thread Next