Re: [PATCH v5 2/3] Makefile: add Perl runtime prefix support
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jan 8, 2018, 20:27 UTC
- Message-ID
- <nycvar.QRO.7.76.6.1801082125210.31@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>
- In-Reply-To
- <20180108191812.52565-1-dnj@google.com>
Hi,
On Mon, 8 Jan 2018, Dan Jacques wrote:
Show 25 quoted lines
> On Mon, 08 Jan 2018, Ævar Arnfjörð Bjarmason replied: > > >>+# it. This is intentionally separate from RUNTIME_PREFIX so that > >>notably Windows +# can hard-code Perl library paths while still > >>enabling RUNTIME_PREFIX +# resolution. > > > > Maybe we covered this in previous submissions, but refresh my memory, > > why is the *_PERL define still needed? Reading this explanation > > doesn't make sense to me, but I'm probably missing something. > > > > If we have a system where we have some perl library paths on the > > system we want to use, then they'll still be in @INC after our 'use > > lib'-ing, so we'll find libraries there. > > > > The only reason I can think of for doing this for C and not for Perl > > would be if you for some reason want to have a git in /tmp/git but > > then use a different version of the Git.pm from some system install, > > but I can't imagine why. > > The reason is entirely due to the way Git-for-Windows is structured. In > Git-for-Windows, Git binaries are run directly from Windows, meaning > that they require RUNTIME_PREFIX resolution. However, Perl scripts are > run from a MinGW universe, within which filesystem paths are fixed. > Therefore, Windows Perl scripts don't require a runtime prefix > resolution.
As I mentioned in the mail I just finished and sent (I started it hours ago, but then got busy with other things while the builds were running): I am totally cool with changing this on Windows, too. Should simplify things, right?
Ciao, Johannes