on_l.
>
> I don't see what such a module would obtain. If a gnulib user
> wants to use strfmon(), they will specify the module 'strfmon'. If
> they want to use strfmon_l(), they will specify the module
> 'strfmon_l'. We don't have a module for "all f
e current git sources :-) I expect the patches will need to go
through a few iterations on this mailing list before being merged,
of course. I've also signed the copyright assignment papers and
sent those off.
Yours truly,
John Zaitseff
--
John Zaitseff,--_|\The Z
u write a nontrivial amount of glue in
> m4/whatever.m4 etc., you'll need to assign copyright to the FSF at
> some point. I can start the ball rolling on that if you haven't
> done it already.
Not sure if I have done that already, but happy to do so for Gnulib
and Glibc.
ple of weeks to come up with a suitable patch or
git repository you can pull from. If so, what is your preferred
procedure for patch submission etc.?
PS: Please include my email address in a CC--I'm not (yet)
subscribed to the Gnulib mailing list.
Yours truly,
John Za
gt; m4/xsize.m4
Now only one file is not included in the generated archive:
m4/gnulib-tool.m4
I'm guessing that that file is not needed for actual building? Is
it a temporary file used by gnulib-tool and thus should be ignored
and treated as a build file only?
Yours truly,
John Zaitseff
--
John Zaitseff,--_|\The ZAP Group
Phone: +61 2 9643 7737 / \ Sydney, Australia
E-mail: j.zaits...@zap.org.au \_,--._* http://www.zap.org.au/
v
u gettext gettext-h gettimeofday locale mbrtowc mbsrtowcs
stdbool stdio striconv string strstr sys_stat sys_time unistd wchar wcrtomb
wcsdup wctob wctype-h
Please let me know if you require any further information.
Yours truly,
John Zaitseff
--
John Zaitseff,--_|\
