Re: gnatsd problems with 4.0.1

["Mark D. Baushke" <mdb@juniper.net>]

Mike M. Volokhov <mishka@apk.od.ua> writes:

> On Thu, 6 Jan 2005 11:04:35 -0600
> Chad Walstrom <chewie@wookimus.net> wrote:
> 
> First, excuse me please for the delayed answer. :-(
> 
> > Mike M. Volokhov wrote:
> > > Could you explain me please what a reason to have libiberty code in
> > > GNATS tree?
> > 
> > For historical and supposedly portability reasons.  Frankly, I'm not
> > that comfortable with it being there.  I haven't had much time lately,
> > but I'd love to audit the GNATS codebase to find out what functions in
> > ./libiberty are actually being used and decide either to adopt them
> > completely by moving them into the ./gnats directory OR drop them
> > completely.  There was a lot of cruft pulled in from my last update.  We
> > can always roll back the CVS to the point before the libiberty update
> > (which I've been contemplating since the day I mistakenly committed it
> > to TRUNK rather than the dev branch like I wanted).
> > 
> > Any opinions in either direction?
> 
> Yes, that's exactly I've asked why. Including libiberty in GNATS
> codebase depends on how much it is used by the project.  Unfortunately,
> libiberty itself seems have not official distribution and in addition it
> may provide some functionality which cannot be acheived by standard C
> library.
> 
> > If someone is willing to do the audit, let me know.  It may not take
> > much time, but most of my spare time right now is going toward a
> > certification class, :-/, and caring for my son, :-).
> 
> I've done some sort of GNATS sources audit to know how much project
> dependends on libiberty code. Well, seems it is not too hard dependent!
> I've used libiberty.h header file to obtain a list of provided functions
> and ran a simple script across gnats/*.[ch] files. It shows a results at
> the end of this mail message.
> 
> So, only six functions are used by GNATS, when libiberty provides about
> 40. Only two functions (asprintf and vasprintf) are nor POSIX nor
> standard C relevant (but included in both GNU and BSD libc). Three
> functions (xstrdup, xmalloc, xrealloc) are totally libiberty-own, but
> can be easy replaced with their standard equivalents.
> 
> Thus, I propose to eliminate dependency on libiberty completely.
> 
> Any comments?

I would suggest consideration of including the GNULIB versions of those
functions as an alternative.

This is much easier than trying to keep libiberty up-to-date.

  cvs -d :ext:anoncvs@savannah.gnu.org/cvsroot/gnulib co gnulib

this does probably make a vote of moving to a use of autoconf and
automake as a part of building the configure and related files in
order to make this easier to use.

The typical approach would be to create a lib and m4 directory for
including the relevant code from a gnulib checkout directory into the
gnats source base. There is a tool that can be used to pull into the
gnats tree any module that GNULIB provides.

See the gnulib/README after you checkout a copy of it.

	-- Mark


_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats