[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: string.h uses restrict

From: Simon Josefsson
Subject: Re: string.h uses restrict
Date: Wed, 01 Apr 2009 17:25:44 +0200
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)

Reuben Thomas <address@hidden> writes:

> On Wed, 1 Apr 2009, Simon Josefsson wrote:
>> It will be easier to review if you post patches for gnulib's maint.mk
>> instead of the entire new file.
> I'll do that.


>> You may have to patch coreutils maint.mk too, but that could go to
>> address@hidden
> I was hoping to end up with a single file that other projects would
> use from gnulib.

Coreutils doesn't use the gnulib maintainer-makefile module, I believe,
so at minimum it would need a patch that made it use maint.mk from

Further, some of the rules in coreutils's maint.mk may not be
appropriate for all projects: for example, some rules assumes that you
use git as the VC which isn't true for all projects that use gnulib.
Such rules could be moved from coreutils' maint.mk to coreutils cfg.mk.
This allows the gnulib maint.mk file to contain generic code.

>> 3. Code coverage rules and gettext rules.
> I've added those back, My small screen makes these things harder to
> spot in ediff...


>> 4. Use of C_SOURCES in sc_* rules.
> There seems to be a conflict here between coreutils's approach (use a
> list of exceptions generated from the VCS) and gnulib's (generate a
> list of files to look at). What do you suggest as a next step? In
> either case, the place to fix seems to be _prohibit_regexp (as
> coreutils's maint.mk factors out the common code into this single
> "macro").

I think the best would be to adapt the gnulib approach, and patch
coreutils to generate the same list of files.  That way, gnulib maint.mk
doesn't have to assume that the vc is git.

Dealing with this problem is the reason I have not worked on this
before, merging the code isn't completely trivial..  another solution
may be to strip down the gnulib maint.mk completely so it doesn't
conflict any more, and move most of the rules in coreutils maint.mk to
coreutils cfg.mk.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]