Hi Peff, On Mon, 9 Jul 2018, Jeff King wrote: > On Mon, Jul 09, 2018 at 10:26:54PM +0200, Johannes Schindelin wrote: > > > > Would it be reasonable to make RUNTIME_PREFIX the default on systems > > > where we _do_ have that support? AFAIK there is no downside to having it > > > enabled (minus a few syscalls to find the prefix, I suppose, but I > > > assume that's negligible). > > > > > > I.e., a patch to config.mak.uname (and possibly better support for > > > _disabling_ it, though I think "make RUNTIME_PREFIX=" would probably > > > work). > > > > The obvious downside is that we would be a lot more likely to break one > > side of the equation. At least right now, we have Git for Windows being a > > prime user of RUNTIME_PREFIX (so breakages should be caught relatively > > quickly), and macOS/Linux *not* being users of that feature (so breakages > > in the non-RUNTIME_PREFIX code paths should be caught even quicker). By > > turning on RUNTIME_PREFIX for the major platforms, the fringe platforms > > are even further out on their own. > > That's true. On the other hand, we have a zillion compat features for > fringe platforms already, so there already is an expectation that people > on those platforms would need to occasionally report and fix > system-specific bugs. Perhaps thinking of it not as an feature to opt > into, but rather as a compat for "your system has not caught up to the > modern world by implementing RUNTIME_PREFIX" would encourage people on > those platforms to implement the necessary scaffolding. > > I also have a gut feeling that it is much easier for static-path devs to > break RUNTIME_PREFIX folks, rather than the other way around, simply > because RUNTIME_PREFIX has a lot more moving parts. But I admit that's > just a feeling. Your gut feeling comes from a lot of experience that I trust. So I'll go with it, too. Ciao, Dscho
