All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Ruud van Asseldonk <dev@veniogames.com>
Cc: Jeff King <peff@peff.net>,
	git@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH] t5150: skip request-pull test if Perl is disabled
Date: Wed, 27 Nov 2019 17:35:01 -0800	[thread overview]
Message-ID: <20191128013501.GB76989@google.com> (raw)
In-Reply-To: <55d0bcd1-1f15-46ff-42f1-be87eedc2e11@veniogames.com>

Hi,

Ruud van Asseldonk wrote:
> Jeff King wrote:

>> I think NO_PERL has historically mostly meant "do not build or install
>> perl scripts", and not "everything ought to run fine without perl".
>> We've generally assumed you can run vanilla perl snippets from the
>> command line the same way you'd run awk or sed (and the tests use this
>> extensively, which is why you have to set PERL_PATH again to run them)

We've definitely held the stance that NO_PERL doesn't mean to disable
perl in tests.  For casual use of perl in installed shell scripts, on
the other hand, I suspect it was more that we forgot about them than
that we had decided one way or another. :)

[...]
>> That said, most of those casual uses of perl in actual built scripts
>> have gone away because the shell scripts have gone away. It looks like
>> filter-branch, request-pull, and instaweb are the last holdouts. So
>> maybe we should be treating NO_PERL as disabling those scripts, too.
>>
>> But then, should we be doing more to make it clear that those scripts
>> are broken in a NO_PERL build? Who knows what happens if you run
>> filter-branch without any perl available?
>
> My understanding was that NO_PERL controlled the runtime dependencies of
> Git, and that the tests require Perl either way. Of course, without Perl any
> scripts that depend on it can't be used, but like you say, there are few of
> them left. I think it would make sense to not install those scripts when
> NO_PERL=1. Should I make a patch to change that in the makefile?

Yes, that sounds good to me.  (The status quo also seems fine to me,
but I like that this proposed approach would simplify things a
little.)

Thanks for working on this, and sorry for the earlier noise.

Sincerely,
Jonathan

  reply	other threads:[~2019-11-28  1:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-26  0:02 [PATCH] t5150: skip request-pull test if Perl is disabled Ruud van Asseldonk
2019-11-26  0:43 ` Jonathan Nieder
2019-11-26  0:46 ` Jonathan Nieder
2019-11-27 22:42   ` Ruud van Asseldonk
2019-11-27 11:21 ` Jeff King
2019-11-27 23:45   ` Ruud van Asseldonk
2019-11-28  1:35     ` Jonathan Nieder [this message]
2019-11-28  1:31   ` Jonathan Nieder
2019-12-02  6:19     ` Junio C Hamano
2019-12-13  7:46       ` Jeff King
2019-12-16 18:32         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191128013501.GB76989@google.com \
    --to=jrnieder@gmail.com \
    --cc=dev@veniogames.com \
    --cc=git@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.