Re: [PATCH] maint.mk: don't maintain a second build-aux variable.

[Gary V. Vaughan]

Hi Jim,

Looks like our messages crossed, please disregard my last reply.

On 25 Oct 2011, at 15:05, Jim Meyering wrote:
> [please configure your mail client to stop including both plain
> and html versions of each message]

If you know of an option to do that on the iPad with iOS5 mobile mail
I'll be very happy to hear about it... in the mean time, I'll try to
remember not to reply to bug-gnulib on my iPad over morning coffee.

> 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.

Agreed, sorry I missed that.

>>    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"?

It seemed as though you were advising that I work around it in my
own cfg.mk.  My misunderstanding, sorry.

> 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.

It's in my queue, so I should get to it in a few days.  Thanks for the
feedback.

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