Re: maint.mk bug (with tentative fix)

[Jim Meyering]

On Wed, Jan 1, 2014 at 5:56 PM, Gary V. Vaughan <address@hidden> wrote:
> Hi Jim,
>
> Thanks for the quick response.
>
> On Jan 2, 2014, at 2:27 PM, Jim Meyering <address@hidden> wrote:
>
>> On Wed, Jan 1, 2014 at 5:08 PM, Gary V. Vaughan <address@hidden> wrote:
>> ...
>>> The change (back ticks instead of $(...) in the no-submodule-changes rule) 
>>> looks like a harmless way to fix the bug to me.
>>>
>>> Okay to push?
>>
>> Hi Gary,
>> I have been unable to reproduce that failure so far.
>> E.g., this via grep (which I have just updated to use the latest from 
>> gnulib):
>>
>>    make no-submodule-changes SHELL=/bin/bash V=1
>>
>> works fine for me using this version of bash and others:
>>
>>    GNU bash, version 4.2.45(2)-release (i386-apple-darwin12.3.0)
>>
>> Many people run rules that depend on the one you're proposing
>> to change, so I suspect that something unusual about your environment is
>> at the root of this.
>>
>> Besides, you know how I feel about backticks vs $()
>> syntax (we should almost always prefer the latter), so am very reluctant
>> to make such changes without understanding the root cause.
>
> Okay...  On a whim, I decided to build my own GNU make, and it turns out that
> this seems to be a problem with the Apple make build shipped with latest Xcode
> command-line tools for (at least) Mavericks 10.9.1 - even though the version
> string indicates the build was rolled at least a couple of releases ago.
>
> $ make --version
> GNU Make 3.81
> Copyright (C) 2006  Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
>
> This program built for i386-apple-darwin11.3.0
>
> make V=1 no-submodule-changes SHELL=/bin/bash
> if test -d ./.git                               \
>                 && git --version >/dev/null 2>&1; then                  \
>           diff=$(cd . && git submodule -q foreach git diff-index --name-only 
> HEAD)            \
>             || exit 1;                                                  \
>           case $diff in '') ;;                                          \
>             *) echo 'maint.mk: submodule files are locally modified:';  \
>                 echo "$diff"; exit 1;; esac;                            \
>         else                                                            \
>           : ;                                                           \
>         fi
> /bin/bash: -c: line 1: syntax error: unexpected end of file
> make: *** [no-submodule-changes] Error 2
>
> $ gmake --version
> GNU Make 4.0
> Built for x86_64-apple-darwin13.0.0
> Copyright (C) 1988-2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> $ gmake V=1 no-submodule-changes SHELL=/bin/bash
> if test -d ./.git                               \
>         && git --version >/dev/null 2>&1; then                  \
>   diff=$(cd . && git submodule -q foreach git diff-index --name-only
> HEAD)                      \
>     || exit 1;                                                  \
>   case $diff in '') ;;                                          \
>     *) echo 'maint.mk: submodule files are locally modified:';  \
>         echo "$diff"; exit 1;; esac;                            \
> else                                                            \
>   : ;                                                           \
> fi
> My hunch about nested parens being the misparsed by Apple's latest make was
> correct, so if you prefer to avoid back ticks entirely, I can pull srcdir out
> of the command substitution for an equivalent fix that also works.
>
> $ make V=1 no-submodule-changes-portable SHELL=/bin/bash
> if test -d ./.git                               \
>                 && git --version >/dev/null 2>&1; then                  \
>           srcdir=.;                                             \
>           diff=$(cd $srcdir && git submodule -q foreach git diff-index 
> --name-only HEAD)            \
>             || exit 1;                                                  \
>           case $diff in '') ;;                                          \
>             *) echo 'maint.mk: submodule files are locally modified:';  \
>                 echo "$diff"; exit 1;; esac;                            \
>         else                                                            \
>           : ;                                                           \
>         fi
>
> I'd like to think enough of us are using Macs for GNU development that it's
> less effort overall to workaround the weird parser bug in maint.mk than force
> everyone to figure out why they need a custom build of GNU make on Mac OS for
> this rule not to error out.
>
> Okay to push one of the above (backticks or pull srcdir out of the $() at your
> preference) along with a comment that Apple ships a buggy make with recent 
> Mac OS
> releases?

Hi Gary,
Glad you found the problem, and that it's not in maint.mk.
One of our tenets relating to developer-related tools/rules like this
is that we do not accommodate inferior tools when it comes to building
from git-cloned sources (by contrast to building from a tarball).
People who do that are expected to be using reasonable tools, and
obviously Mac OS's patched GNU "make" does not qualify.  I would
suggest to add code that would detect the buggy make (perhaps even at
configure time), and abort the build process with a diagnostic.
Accommodating such broken tools is not doing the user a favor in the
long run: they'll surely encounter it again, in another context,
eventually, so it's best to send a clear message.