Subject: Re: [PATCH v2 0/5] miscellaneous build mods (part 2)

From: Junio C Hamano <[email-masked]>
Date: Tue, 13 May 2025 13:13:57 -0700

Ramsay Jones <[email-masked]> writes:

> Changes in v2:
>
> Patch #3 is the only one changed (as a result of Patrick's review [0]):
>
>  - add some blank lines to make the option handling blocks
>    easier to see.
>  - add a comment to 'gitconfig' and 'gitattributes' options
>    to indicate the default values.
>
> Note: The indicated defaults for the 'gitconfig' and 'gitattributes'
> are only valid when the 'prefix' option is defaulted (or not /usr).
> Indicating the 'correct' value when -Dprefix=/usr in the comment
> would consume too much space. Is this acceptable, or is it too
> confusing/misleading?
>
> Also, thanks to Eli for testing patch #5 on Solaris and confirming
> that it fixes the regression [1].

Yeah, thanks, all.

> A range-diff against v1 is given below.
> ...
> 3:  fece809f11 ! 3:  a385bbed83 meson: correct path to system config/attribute files
>     @@ meson.build: libgit_c_args = [
> ...
>         description: 'Environment used when spawning the pager')
> 4:  d49afaedf3 = 4:  0d00951475 meson.build: correct setting of GIT_EXEC_PATH
> 5:  69848e557f = 5:  150e4110d2 configure.ac: upgrade to a compilation check for sysinfo

Hmph, For #5 I am seeing this difference:

    @@ Commit message
         Commit 50dec7c566 ("config.mak.uname: add sysinfo() configuration for
         cygwin", 2025-04-17) added a similar 'sysinfo()' check to the autoconf
         build. This check looked for the 'sysinfo()' function itself, rather
    -    than just the header, but it will fail (incorrectly set HAVE_SYSINFO)
    +    that just the header, but it will fail (incorrectly set HAVE_SYSINFO)
         for the same reason.
     
         In order to correctly identify the 'sysinfo()' function we require as

The original comes from what was posted in the first iteration, and
somehow the change is not showing in your range-diff, which is a bit
disturbing.

I think for now I'll just amend the log message of #5 back to what
was in the previous round locally.

Thanks.