On Mon, Dec 29, 2014 at 10:57 PM, Randy J. Ray <rjray@xxxxxxxxxxxxx> wrote: > On 12/29/14, 7:40 AM, Torsten Bögershausen wrote: >> >> Having problems with different perl installations is not an unknown >> problem >> in Git, I would say. >> >> And Git itself is prepared to handle this situation: >> >> In Makefile I can read: >> # Define PERL_PATH to the path of your Perl binary (usually >> /usr/bin/perl). >> >> (What Git can not decide is which perl it should use, the one pointed out >> by $PATH or /usr/bin/perl.) >> >> What does >> "type perl" say ? >> >> And what happens when you build and install Git like this: >> PERL_PATH=/XX/YY/perl make install >> >> ----------- >> Are you thinking about changing >> ifndef PERL_PATH >> PERL_PATH = /usr/bin/perl >> endif >> -- into -- >> ifndef PERL_PATH >> PERL_PATH = $(shell which perl) >> endif >> --- >> >> At first glance that could make sense, at least to me. > > > The problem in this case is the Perl being used at run-time, not build-time. > The building of git is done by the homebrew project in this case, so I don't > have direct control over it. Correct, but we don't change /usr/bin/perl at runtime, we hardcode that at compile-time. Similarly we could hardcode PERL5LIB at compile-time, but we don't, if we did you wouldn't have this problem. I.e. the problem is that we're using the system-provided perl with a custom PERL5LIB set for the benefit of a non-system provided perl installed after you built Git (or built in a different environment...) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html