[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnatsd problems with 4.0.1
Mark D. Baushke
Re: gnatsd problems with 4.0.1
Mon, 07 Feb 2005 09:09:20 -0800
Mike M. Volokhov <address@hidden> writes:
> On Thu, 6 Jan 2005 11:04:35 -0600
> Chad Walstrom <address@hidden> 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
> > 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:address@hidden/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.