Re: FYI: gnulib now available at toplevel of binutils-gdb.git

[Joel Brobecker <brobecker@adacore.com>]

Hi Nick,

> > The "gnulib" copy maintained by the GDB community has recently been
> > moved to the toplevel directory (in an effort to share the build
> > artefacts between GDB and GDBserver, IIUC). Within the GDB group,
> > we have found this library to be extremely useful, and perhaps
> > the binutils group will want to use it too.
> 
> Do you have some examples of how gnulib has helped GDB ?

A few situations come to mind:

  - some features missing from the system's libc -- e.g. we've had
    cases were some functions, or some macros were missing; same
    for types (e.g. stdint.h);

  - some functions are present, but misbehaving;

  - some functions/macros are present, but non-complient.

Generally speaking, gnulib helped us at numerous times enhance
portability without having to deal with portablity ourselves.
I can't imagine what it would have been like without gnulib.

> I am all for reusing code, and especially sharing between the binutils
> and GDB, so if there is a use case for us then I would be happy to
> consider it.

If you've never looked at gnulib before, here is a link to their web
page: https://www.gnu.org/software/gnulib/

The nice thing about it is that it's very modular. Modules have
inter-dependencies, of course, but you can still pick and choose
what you actually need.

GDB eventually created an import structure, so that we have a clear
idea of what it is that we're using, and we can easily reproduce
imports. See gnulib/update-gnulib.sh which contains the list of
modules we use as well as automates imports.

I don't know that the binutils project should rush towards using it
ASAP. However, with knoweledge that the structure is now in place,
perhaps you'll find one day that some portability-oriented work
that you would normally take care of in house might already be
handled by gnulib, at which point you might consider its use...

One possible example of that, although I am not sure this is the best
example, but anyways, is the compilation issues we had with libctf,
where it didn't build on Windows because it was using errno macros,
with one of them not existing on mingw32.

> > In the meantime, there is one slightly trivial question that
> > we want to ask: Do you guys want us to restrict commit emails
> > for changes in this directory to go solely to the gdb mailing-list?
> 
> No thanks - I think keeping the binutils in on the discussions would
> be valuable.

Cool. So we're all set in terms of the emails.

-- 
Joel