Paul Eggert wrote:
> This burned another hour of my time. I suppose I should bump the
> priority of getting bootstrapping to work with coreutils.
The bidirectional merge between gettext and gnulib after gettext-0.15
took me 5 hours. Then I switched to using gnulib-tool. The number of
files maintained in gettext is:
in lib/ in m4/
before (manual updates) 173 59
after (gnulib-tool automatic) 43 12
So the use of gnulib-tool frees me from regular updates to more than 150
files (76% of the files).
I would say that thanks to the changes to gnulib-tool two weeks ago,
gnulib-tool now has enough flexibility for being usable in coreutils:
- It allows to keep some minor diffs indefinitely,
- It allows to override entire files by storing the overriding files,
- It allows to omit files, simply by removing them from the module
description.
Take a look at the gettext CVS (subdirectory 'gnulib-local') to see what
it looks like.
http://cvs.savannah.gnu.org/viewcvs/gettext/gnulib-local/?root=gettext
http://cvs.savannah.gnu.org/viewcvs/gettext/autogen.sh?rev=1.24&root=gettext&view=auto
> On the
> other hand, even if I did that the resulting tarball would contain a
> lot of mingw cruft that hinders maintenance.
>
> Perhaps we should change things so that gnulib assumes by default that
> you don't want to support mingw, and that you can use a new 'mingw'
> module if you prefer to to support it. That would help folks like me
> who don't want to bother with mingw's porting hassles.
I think the majority of gnulib users (*) want portability to mingw, and
coreutils is in a minority position. Therefore I would suggest that
you first try the --avoid option to get rid of modules like sys_socket
and sys_select, and if that doesn't work out, selectively hide mingw
portability by using the gnulib-tool overriding features.
Bruno
(*) I added to gnulib a file users.txt listing the uses of gnulib that
I found so far.
