Re: maint.mk bug (with tentative fix)

[Jim Meyering]

On Wed, Jan 1, 2014 at 6:33 PM, Gary V. Vaughan <address@hidden> wrote:
> Hi Jim,
>
> On Jan 2, 2014, at 3:22 PM, Jim Meyering <address@hidden> wrote:
>> 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.
>
> That's not unreasonable.
>
> My main contention is that I don't want to have to carry a separate
> configure test, or cfg.mk snippet, around between all my projects; none
> of which helps the next Mac OS using GNU developer understand why gnulib
> `make release` is broken for them.
>
> I really think the best place to diagnose the problem is at the source,
> but I no longer know my way around the innards of gnulib well enough to
> spot the right place to add the detection and diagnosis.
>
> Assuming I can come up with a short test to detect the buggy make, do
> I add code to maint.mk:no-submodule-changes to diagnose the actual
> problem before encountering the cryptic shell error (with a sub-make
> invocation to avoid crashing the detecting make process)?

Adding to maint.mk sounds like the right approach.
One possibility is to add a separate minimal-reproducer rule,
upon which no-submodule-changes depends.  In that new rule
you would want to eval the offending code, so it can't terminate
the entire make process.  That would be preferable to running an
entire sub-make, if possible.