bug-gnulib
[Top][All Lists]
Advanced

[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: Tue, 14 Apr 2009 22:42:29 +0200
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)

Jim Meyering <address@hidden> writes:

> Simon Josefsson wrote:
>> Reuben Thomas <address@hidden> writes:
>>
>>> On Wed, 1 Apr 2009, Simon Josefsson wrote:
>>>
>>>> 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
>>>> gnulib.
>>>
>>> Or it could use maintainer-makefile, unless there's some reason why not?
>>
>> Right, I think coreutils should use maintainer-makefile.
>
> ;-)
> In the long run, of course.
> But coreutils certainly can't do that now.
> I'll be happy to switch as soon as doing so is not a step backwards.

Understood.  I think taking most of coreutils maint.mk and putting that
into gnulib is something we should consider.  I suspect all the
non-coreutils-related projects can cope with having to review maint.mk
for anything that doesn't work.

> I'm using coreutils' maint.mk in 3 or 4 other projects,
> nearly verbatim.  As such, I'm reluctant to remove rules, since
> that would mean migrating them out to each cfg.mk, which is maintained
> separately, and thus harder to keep in sync.  Besides, unwanted rules
> are easy to disable.

I don't follow -- if you maintain your copies of maint.mk which are
similar but not identical in some way today, can't you use the same
strategy for cfg.mk?

However, ideally I think all of what's in coreutils maint.mk should go
into gnulib maint.mk.  So the stuff you need to maintain in cfg.mk will
be minimal and project-specific.  If it isn't project specific, it is
something that should go into gnulib's maint.mk.

/Simon




reply via email to

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