Re: Can git choose perl at runtime?

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Dec 19, 2018, 03:17 UTC
Message-ID: <20181219031752.GA181843@google.com>
In-Reply-To: <CAJdN7Kioa22xrDP2ssZXmBbu7KDkcr2MQCUDW=Tzm5ydzeChBQ@mail.gmail.com>

Hi John,

John Passaro wrote:

Show 15 quoted lines

> https://public-inbox.org/git/878t55qga6.fsf@evledraar.gmail.com/
>
> The struggle is that Mac's package manager Homebrew has opted,
> apparently with some finality, to no longer support linking to a user
> perl at build time. PERL_PATH is hard-coded to link to the system
> perl, which means the user needs sudo to install the SSL libraries
> required for send-email. So for send-email to work, you need to either
> sudo cpan or build git yourself. The obvious solution here would be to
> do /usr/bin/env perl, but in the above message Aevar pointed out
> pitfalls with that.
>
> It seems that choosing perl at compile time necessarily comes with
> tradeoffs. So I wonder if there is a way we can support choosing a
> perl at runtime without breaking the existing mechanism of linking to
> perl at compile time.

I haven't carefully looked at your exact proposal, but I just wanted to offer you my support: yes, I would love to see some solution. Thanks for looking into it.

It would let me remove this bit of horror from my local build script:

 APIVER_EXPR='@{[sub{use Config; $$Config{api_version}}->()]}'
 XCODE_PERL="/Applications/Xcode.app/Contents/Developer/Library/Perl/5.$APIVER_EXPR/darwin-thread-multi-2level"
 make ... PERLLIB_EXTRA="$XCODE_PERL"

(My apologies.)

[...]

Show 5 quoted lines

> That does mean we have a new command to support and document: "git
> perl". If it is preferred to keep this hidden as an implementation
> detail, we could call the executable something like "util-git-perl"
> instead so that it doesn't show up when scanning libexec for git
> commands.

Typically we handle this kind of thing by putting a double-dash in the command name. See git-sh--setup, for example.

Thanks and hope that helps, Jonathan