Re: Sync maintainer-makefile files

[Simon Josefsson]

Micah Cowan <address@hidden> writes:

> Simon Josefsson wrote:
>> Micah Cowan <address@hidden> writes:
>> 
>>>> The second set of patches is against gnulib to remove most of the rules
>>>> in coreutils, to avoid duplication.  This removes some features from
>>>> gnulib's maint.mk, but has anyone been using them heavily?  If so, we
>>>> can add them again by making small incremental patches against coreutils
>>>> and gnulib.
>>>>
>>>> Thoughts?
>>> Didn't you just remove the vast majority of targets from maint.mk?
>>> There's barely anything left at all! Why bother having a maint.mk in the
>>> first place then?
>> 
>> It isn't completely empty, and more importantly, it serves as a place
>> holder for things to move from coreutils.
>
> Is coreutils' maint.mk essentially a superset of gnulib's, then?

Yes.  Everything in gnulib's maint.mk comes from Coreutils
Makefile.maint originally.

>>> I have only just begun using it, but I find all of the following useful:
>>>
>>>> -sc_cast_of_argument_to_free:
>>>> -sc_cast_of_x_alloc_return_value:
>>>> -sc_cast_of_alloca_return_value:
>>>> -sc_space_tab:
>>> ^^  *especially* that one...
>>>
>>>> -sc_changelog:
>>>> -syntax-check: $(syntax-check-rules)
>>> Throwing out several useful rules, which AFAICT make up almost the
>>> entirety of maint.mk, just because coreutils already has them, is a bad
>>> move, IMO.
>> 
>> Once we have made coreutils use the gnulib module for these files, would
>> you be interested in working on merging back the rules from coreutils to
>> gnulib?  You could propose patches for both coreutils and gnulib.  Many
>> of the rules will need to be thought through because coreutils have
>> several assumptions that doesn't hold in gnulib.
>
> Perhaps; but it's not clear to me why it's necessary to delete the
> existing rules from gnulib in order to migrate them from coreutils.
> Can't we just migrate any changes to them one by one?

Sure, but someone needs to do that work.  It seems that the current
problem is that there is code duplication between gnulib and coreutils,
and that problem is solved by my patch.

> Since the Gnulib usage model involves grabbing the latest via Git or
> CVS, I would expect Gnulib's repos to be in a pretty stable point at any
> particular point in time. If you apply the proposed patch, then anyone
> who does a pull and a gnulib-tool --update may be surprised to find
> their favorite maint.mk rules suddenly vanish, until such time they are
> reinstated from coreutils.
>
> May I suggest that, if it is really most convenient to do it this way,
> the mainline repo be cloned to a special-purpose one to work on this, so
> that the mainline itself may retain full functionality, and that
> coreutils use that one during migration to gnulib's maintainer-makefile?

That could work too, although I think that gnulib users should be
prepared to adapt to changes.

Alternatively, we could start a completely new gnulib module
'maintainer-makefile2'.  That would make it easy to start
synchronization between coreutils and gnulib, which is the most
important step.

Anyway, I think it should be up to the coreutils maintainers what to do
here.

/Simon