Re: Git 2.18: RUNTIME_PREFIX... is it working?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux