Eric Blake wrote: > I tweaked some of the > wording: since cc and make are used by the end user, while the rest of the > tools are developer-only, using native cc and make instead of gcc and > gmake helps test portability.
As you like. But I don't agree with two of these changes: > + + VPATH builds often need GNU make 3.79.1 or newer. Please, can you remove that word 'often'? I'm not going to modify gnulib for the sake of half-baken VPATH "implementations". This would be a waste of time. And it's dishonest to say that maybe we support VPATH of Solaris or BSD make if, in fact, we are not willing to spend time on it. > -* GNU m4 1.4.9 or newer. > +* GNU m4 1.4.5 or newer. Ultimately, you know better than anyone else what's in which version of GNU m4, but when I read this: http://lists.gnu.org/archive/html/bug-gnulib/2006-12/msg00247.html or the m4/NEWS of 1.4.9: * Fix a regression introduced in 1.4.8 that made m4 dump core when invoked as 'm4 -- file'. 1.4.7: * Fix regression from 1.4.5 in handling a file that ends in a macro expansion without arguments instead of a newline. 1.4.6: * Fix buffer overruns in regexp and patsubst macros when handed a trailing backslash in the replacement text, or when handling \n substitutions beyond the number of \(\) groups. * Fix memory leak in regexp, patsubst, and changeword macros. * When loading frozen files, m4 now exits with status 63 if version mismatch is detected. it makes me feel uncomfortable with any version < 1.4.7. Especially your memory leak fixes had a tremendous positive effect on my machine. > A bit strong on the m4 requirements, since debian stable doesn't ship > 1.4.9 yet (I only released it last month :). It's irrelevant what Debian ships: users who have access to the gnulib git or cvs repository also have access to ftp.gnu.org and can install new versions of GNU software. Bruno
