Hi Jim, On Jan 2, 2014, at 3:22 PM, Jim Meyering <j...@meyering.net> 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
