On Mon, Jan 08 2018, Dan Jacques jotted: > 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? To be clear, I meant that if it's determined by you/others that an opt-out on Windows is needed I think it makes sense to make it a NO_* flag, but if there's a solution where we can just turn it on for everything then ideally we'd just have RUNTIME_PREFIX=YesPlease.
