Front page | perl.perl5.porters |
Postings from September 2016
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=129229Thread Previous | Thread Next