bug-inetutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-inetutils] gnulib


From: Alfred M. Szmidt
Subject: Re: [bug-inetutils] gnulib
Date: Thu, 8 Mar 2007 12:50:56 +0100 (CET)

   > Any thoughts on this?  Does anyone object to removing gnulib if
   > it is easy to regenerate it all running a script like autogen.sh?

   Both tar and cpio traditionally do this way, providing a special
   `bootstrap' script that gets all the gnulib stuff from cvs prior to
   running autoconf. This has been the source of various problems for
   me as the maintainer, and much more for the users who wished to
   build CVS versions.

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.

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. :-)

   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.

   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).

As I see it, we will always have to keep things updated, auto* comes
out once in a while with some minor incompatible changes as well so we
need to tweak configure.ac.  Keeping things synced up seems like a
good idea to me.

   On the other hand, in Mailutils we keep gnulib stuff in the
   repository, updating it from time to time when the need arises. In
   my opinion, it has proven to be a better approach.

I found this to cause troubles for me, since we do not keep auto*
generated files, and gnulib tends to require a specific version of
auto* to be happy.  So I ended up with a new (automake 1.9.6, autoconf
2.60) auto* set, but a really old gnulib.

Cheers!




reply via email to

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