Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > On Mon, 8 Jan 2018, Dan Jacques wrote: > >> 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? Wonderful to see that you two are in agreement. Will look forward to see a simplified solution in a later round ;-)
