On 2018-01-08 20:27, Johannes Schindelin wrote: > > 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 the reason is to accommodate Windows, I think it'd make more sense to > change the way Git for Windows handles this, and use the same relative > paths (if possible, that is, see the GITPERLLIB problems I mentioned > elsewhere and which necessitated > https://github.com/git-for-windows/git/commit/3b2f716bd8). > (...) > What do you think? Should we just fold the RUNTIME_PREFIX_PERL handling > into RUNTIME_PREFIX and be done with that part? > (...) > 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? No objections here. I see it as adding slightly more risk to this patch's potential impact on Windows builds, but if Git-for-Windows is okay with that, I'll go ahead and fold RUNTIME_PREFIX_PERL into RUNTIME_PREFIX for simplicity's sake. I'll add a "NO_RUNTIME_PREFIX_PERL" flag as per avarab@'s suggestion as a potential mitigation if a problem does end up arising in Windows builds, with a note that NO_RUNTIME_PREFIX_PERL can be deleted if everything seems to be working. What do you think? > BTW I managed to run your `runtime-prefix` branch through VSTS builds on > Windows, macOS and Linux and they all pass the test suite. (Including the > RUNTIME_PREFIX_PERL=YesPlease setting you added for Travis CI testing.) Great news, thanks for doing this!
