On Wed, Jan 1, 2014 at 5:56 PM, Gary V. Vaughan <g...@gnu.org> wrote: > Hi Jim, > > Thanks for the quick response. > > On Jan 2, 2014, at 2:27 PM, Jim Meyering <j...@meyering.net> wrote: > >> On Wed, Jan 1, 2014 at 5:08 PM, Gary V. Vaughan <g...@gnu.org> 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.
