Re: maint.mk bug (with tentative fix)

[Gary V. Vaughan]

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)?  Add an m4 macro
to the maintainer-makefile module that gets added to every maint.mk
project's configure by gnulib-tool?  Hopefully you have something in
mind with less overhead than either of those?

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

signature.asc
Description: Message signed with OpenPGP using GPGMail