patchTry 2: Allow PERL_PATH="/usr/bin/env perl"

The perl scripts start with "#!/usr/bin/perl". There is a mechanism PERL_PATH in the Makefile to change this, but it currently doesn't work with PERL_PATH="/usr/bin/env perl". This is causing problems in MacPorts, where we wish to work with the MacPorts perl if it is installed, but fall back to the system perl if it isn't.

Signed-off-by: Bryan Larsen <bryan@larsen.st>
---
  perl/Makefile |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

Bryan Larsen <bryan@larsen.st> writes:

I do not get this whole business. Why would you even want to support that to begin with?

The purpose of PERL_PATH is for you to tell git the path you have your Perl at. It is not about supplying a small shell script that lets "env" to figure it out.

Junio C Hamano wrote:

Maybe PERL_PATH should be renamed PERL_SHEBANG or something. Because if you pass in something that doesn't work on a shebang line (longer than 32 characters, say), it just won't work.

I was under the impression that "#!/usr/bin/env perl" was the "right" way to invoke perl. But I'm not doing this because I want to do the "right" thing. I'm doing this because it makes this scenario work:

$ sudo port install git-core installing openssl... installing openssh... installing curl... installing expat...

$ ... $ git-send-email ... $ ...

$ sudo port install git-svn installing apr... installing subversion... installing perl... installing p5-svn-simple...

git-core works fine with stock perl, and we don't want to install extra megabytes of unneeded stuff if it really isn't needed.

Certainly there are other ways of making this work. But they're all uglier than doing the "right" thing of "/usr/bin/env perl".

cheers, Bryan

P.S. On Linux, "#!/usr/bin/env perl -w" doesn't work. On OS X it works fine.

Bryan Larsen <bryan@larsen.st> writes:

I think I see what problem you are trying to solve better now. Probably more relevant example on MacOS would be whitespace in the pathname.

I think using the bare $(PERL_PATH) in perl/Makefile is a reasonable solution.

Are they any other issues on MacOS? For example, gitweb.cgi is built by replacing the shebang with $(PERL_PATH); I presume that you already are successfully working around the whitespace in the pathname with your "env perl" on MacOS?

I haven't used gitweb.cgi. All the tests run, including the git-send-email test. (t4200 patch was sent a couple of days ago). I know there are several people using git very successfully from MacPorts.

The biggest problem in OS X has been that the BSD versions of standard programs such as xargs and sed are used instead of the GNU versions. There are currently no problems of that sort.

cheers, Bryan

On Thu, May 03, 2007 at 04:02:26PM -0700, Junio C Hamano wrote:

The biggest problem being that on macs it is typical to have two copies of perl installed (/usr/bin/perl and /opt/local/bin/perl with DarwinPorts or otherwise). It'd be nice to have a way to tell git makefiles to put #!/usr/bin/env perl at the top so it just pulls what is first in the path rather than having to hardcode it to either /opt/local/bin/perl or /usr/bin/perl.

Say you are packaging a mac os x package of git. Now for the user to run something like git-svn they'd need the svn bindings obviously, but of course, some people install them against their system perl, lots of people install them against their darwinports or otherwise, and it'd be really nice to just have those various perl scripts use whatever the person has set up (going by what they have first in their path).

- Andy