[please configure your mail client to stop including both plain
and html versions of each message]
Gary V. Vaughan wrote:
> To what advantage over factoring out the duplication entirely at the
> source of the problem with the patch I submitted?
Not breaking some project's existing set-up when
they next update from gnulib.
Alerting the user that they need to change something
to make these two values consistent.
> Wouldn't that break things for those who customize build_aux?
>
> Yes, and that's the problem I encountered that inspired me to
> send a patch to fix it.
It would be better to alert them to the problem.
> How about merely ensuring that they're consistent, for now,
> i.e., by adding something like this:
>
> ifneq ($(build_aux),$(_build-aux))
> $(error ...)
> endif
>
> Do you mean:
>
> ifneq ($(srcdir)/$(_build-aux), $(build_aux))
> $(error ...)
> endif
>
> in GNUmakefile? or in maint.mk? or in cfg.mk?
It belongs in maint.mk, since all uses of build_aux are there,
and there are more of them than of _build-aux in GNUmakefile:
$ cd top && grep -c build_aux GNUmakefile maint.mk
GNUmakefile:0
maint.mk:7
Definitely not in cfg.mk, since that is not distributed via gnulib.
> Again, what's the advantage of kludging it instead of just making
> GNUmakefile and maint.mk use the same variable name for the
...
"kludge"?
We who work on gnulib try hard not to let changes there cause
silent malfunction in client packages. When we must make
changes that may break clients, it is only as a last resort,
and preferably with automated warning. The minimal requirement
is to warn about such a change in NEWS.
Actually, I think we can both get what we want.
I suggest to adjust your patch so that make is guaranteed to fail
with a nice diagnostic for anyone who defines build_aux in cfg.mk.
