On 2021-05-21 at 10:04:53, Jeff King wrote: > On Fri, May 21, 2021 at 01:55:32AM +0000, brian m. carlson wrote: > > Things in contrib are not built by default because they don't > > necessarily work everywhere. For example, the osxkeychain credential > > helper won't compile on Linux because the requisite shared libraries > > are specific to macOS. You'll need to compile them manually and install > > them in a suitable location. > > I agree with this, but just following up with a bit of a devil's > advocate: why not put osxkeychain into a regular "make install", but > make it conditional via a Makefile knob, like we do for other > platform-specific features? Sure, let's do it. For osxkeychain, it's probably pretty simple to always build it, since macOS will always have the appropriate libraries if the compiler is installed. I would be in favor of also building by default on Linux and having a Makefile knob to disable that, since the requisite libraries are a part of nearly every distribution and doing so will spur distros to ship it, which many do not. > And yet, my impression is that basically every Git user on macOS is > using it every day, because both Apple Git and homebrew build it by > default (and I think at least in the case of Apple Git, it's hard-coded > into the config). A little scary, but nobody seems to have complained. :) > > I wonder if we could build it and run it through t0303 as part of the > mac CI process (though I recall at the time that it was really finicky > for automated testing; it wouldn't even run over an ssh session). > > Likewise, we probably could be building and testing the libsecret ones > via the Linux CI job (I don't use those either myself, but presumably > they pass t0303). Running the tests will be harder. macOS, I believe, requires an interactive session to have the keychain unlocked, and on Linux, you require gnome-keyring or an equivalent daemon running, which practically means that you need a desktop session. -- brian m. carlson (he/him or they/them) Houston, Texas, US