Re: Git configure/make does not honor ARFLAGS

[Junio C Hamano <gitster@pobox.com>]

Jeffrey Walton <noloader@gmail.com> writes:

>> Oh, indeed. ac179b4d9. Looks good to me.
>>
>> My follow-up question was going to be: is this something we should be
>> setting in config.mak.uname for appropriate versions of Darwin? It
>> wasn't clear to me from Eric's description if this is something that
>> particular versions need, or just something that people who want to
>> build Universal binaries would choose to use.
>>
> If you have something that needs testing, then please let me know. I'd
> be happy to test it for you.

In your copy of Git that is recent enough, please run this:

    $ git fetch git://git.kernel.org/pub/scm/git/git.git pu
    $ git checkout -b jw/make-arflags-customizable ac179b4d9

This gives you a rather old maintenance track of Git based on v2.0.5
plus a patch that makes $(ARFLAGS) customizable.

Presumably you are building a more recent versions of Git yourself.
I do not know which branch you are on, but you should be able to
merge this brancch to anything newer than v2.0.x maintenance track.
E.g.

    $ git checkout master
    $ git merge jw/make-arflags-customizable

should merge cleanly and would let you say things like:

    $ make AR=libtool ARFLAGS='-static -o'

with any other build customization you usually use on the command
line (or in config.mak, if you prefer).

What Jeff King was wondering was if those on platform like you have
would benefit if they have something like the attached patch on top
of the ac179b4d (Makefile: allow $(ARFLAGS) specified from the
command line, 2015-09-10) patch.  Pieces of information that is
needed to determine if that is a good idea are:

 * What exact condition we should use in the "ifeq" to identify the
   class of platforms that want this custom AR/ARFLAGS.

 * Ask if everybody who shares that particular platform would always
   want "libtool" and "-static -o" as their custom AR/ARFLAGS.  If
   the answer is "no", i.e. on the same platform, more than one
   compiler toolchain may be available to the users and not
   everybody may want to use "libtool" and "-static -o" lie you do,
   then the approach to auto-determine this settings does not help
   people, and we should not bother with shipping customized
   config.mak.uname (instead we'd just tell people to do whatever
   they want with AR and ARFLAGS from the command line).

 * If it is worth shipping customized config.mak.uname, determine
   what things, other than AR/ARFLAGS, would help the uses of the
   class of platforms we identified above in the new "ifeq" section
   (e.g. perhaps they may want CC=some-other-cc).

 config.mak.uname | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/config.mak.uname b/config.mak.uname
index 943c439..247dfed 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -46,6 +46,10 @@ ifeq ($(uname_S),GNU/kFreeBSD)
 	DIR_HAS_BSD_GROUP_SEMANTICS = YesPlease
 	LIBC_CONTAINS_LIBINTL = YesPlease
 endif
+ifeq ($(uname_S),"whatever jeffrey uses")
+	AR = libtool
+	ARFLAGS = -static -o
+endif
 ifeq ($(uname_S),UnixWare)
 	CC = cc
 	NEEDS_SOCKET = YesPlease