On 08/03/07, Alfred M. Szmidt <[EMAIL PROTECTED]> wrote:
We already require the users to have specific versions of auto* installed, I was very suprised that we didn't keep those files in CVS while we keep gnulib. I wouldn't even be raising this issue if we keep all autogenerated files in the CVS tree.
I argues most strongly against keeping autogenerated files in CVS, iirc. Since I tend to use versions that are all over the place, it means that it was constantly committing stupid changes that I didn't want unless I took extra care.
As for users building CVS versions, I, or someone, could make snapshots of the tree that has all the autogenerated files. I'm quite familiar with wanting to build things from CVS but cursing over the fact that the systsem I'm compiling on doesn't have the right version of FOO. :-)
I tend to keep the argument that projects not using the most recent versions of the autotools are inherently broken and require patches and cajoling of the maintainers until its fixed. =)
The gnulib stuff changes very quickly, which requires constant fiddling with the bootstrap script to keep it up to date. Meyering promised that the bootstrap script would be included into gnulib, so I think this problem would vanish.
Any chance of autoreconf just picking it up? It was discussed when I first started the gnulib project, but we thought the interface to it wasn't going to be settled, so we didn't want to cause troubles for the rest of the autotools.
Moreover, sometimes the interfaces provided by the library change in subtle way, introducing unwanted behaviors or bugs (e.g. a function that used to return pointer to the statical storage begins returning a pointer to the allocated memory, causing memory leaks).
This shouldn't be true for replacement glibc and posix-replacement functions. For other helper functions that can't also be found in glibc it could be. I don't suspect it happens as often as this paragraph suggests. Tks, Jeff Bailey -- Jeff Bailey - http://www.raspberryginger.com/jbailey/ _______________________________________________ Bug-inetutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-inetutils
