Re: ab/make-bin-wrappers (was: What's cooking in git.git (Nov 2022, #01; Thu, 3))

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 08, 2022 at 09:27:50AM -0500, Jeff King wrote:
> On Mon, Nov 07, 2022 at 03:33:40PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> >
> > On Thu, Nov 03 2022, Taylor Blau wrote:
> >
> > > * ab/make-bin-wrappers (2022-10-31) 4 commits
> > >  - Makefile: simplify $(test_bindir_programs) rule by splitting it up
> > >  - Makefile: rename "test_bindir_programs" variable, pre-declare
> > >  - Makefile: define "TEST_{PROGRAM,OBJS}" variables earlier
> > >  - Makefile: factor sed-powered '#!/bin/sh' munging into a variable
> > >
> > >  Resolve issues with the bin-wrappers/% rules where "make
> > >  bin-wrappers/git" would generate the script but not "git" itself.
> > >
> > >  Waiting for review.
> > >  source: <cover-v3-0.4-00000000000-20221031T222249Z-avarab@xxxxxxxxx>
> >
> > On my end I'm waiting to see what you and/or Jeff think about:
> > https://lore.kernel.org/git/221101.86edun5tgn.gmgdl@xxxxxxxxxxxxxxxxxxx/
>
> I don't have any strong opinion on that. I read the v2 cover letter, was
> skeptical/confused of the motivation, and didn't go much further.
>
> Your explanation in the linked email is that there are _other_ reasons
> to do this refactoring, but I don't have any knowledge there that would
> add to the review. My gut is still that building bin-wrappers/foo
> doesn't need to depend on foo, but if it's one line, I don't care that
> much either way. If it was 50 lines of complicated Makefile refactoring,
> then would probably not be worth it.

Isn't this topic exactly the latter? IOW:

    $ git diff --stat master...ab/make-bin-wrappers
     Makefile | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------
     1 file changed, 52 insertions(+), 20 deletions(-)

...maybe that was exactly your point ;-).

TBH, I am not sold whatsoever on the premise of that series, and agree
that plodding through 50+ lines of complicated Makefile diff is
difficult to justify when the premise is hazy to me.

Ævar, any strong objections against dropping this one? If there is a
simpler way forward, I'm all ears, but in the meantime I find it
difficult to justify the review time as-is.

Thanks,
Taylor



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux