Hi John, John Passaro wrote: > https://public-inbox.org/git/878t55qga6.fsf@xxxxxxxxxxxxxxxxxxx/ > > 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.) [...] > 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
