Re: Should we import gnulib under gcc/ or at the top-level like libiberty?

[Pedro Alves <palves at redhat dot com>]

On 06/23/2016 03:54 PM, Szabolcs Nagy wrote:

> if both gcc and binutils used a toplevel gnulib directory
> then shared tree build would have the same problem as
> libiberty has now: gcc and binutils can depend on different
> versions of libiberty and then the build can fail.
> as far as i know the shared tree build is the only way to
> build a toolchain without install (using in tree binutils)
> and it would be nice to fix that use case.

Sharing/not-sharing vs top-level-or-not are orthogonal issues.

As you note, combined tree conflicts are not a new issue introduced
by the potintialy shared top level gnulib.  A way to sort that out
that crosses my mind immediately, would be give gcc's and binutil's copies
different top level directory names, like say libiberty-gcc
and libiberty-binutils or some such.  You'd need to do the same
to shared files in the include/ directory, and probably others
that I'm not recalling off hand.  So if we wanted to aim for that, we
could call the new toplevel directory gnulib-gcc or some such.

IMO, combining gcc and binutils trees of different enough vintage
can't be guaranteed to work, so my suggestion is to treat that
as "it hurts when I do this; then don't do that".

Frankly, the idea of sharing a single gnulib import between
gcc and binutils-gdb scares me a bit, because on the gdb side
we're used to only care about making sure gdb works when we
need to think about  importing a new module.  Not that it
happens all that often though; maybe once a year.

But on the other hand, the idea of maintaining multiple gnulib
copies isn't that appealing either.  Considering that the long
term desired result ends up with a libiberty that is no longer a
portability library, but instead only an utilities library, then to
get to that stage, the other programs in the binutils-gdb repo which
rely on libiberty too, binutils proper, gas, ld, gold, etc., need
to be converted to use gnulib as well.  And then a single
gnulib sounds even more appealing.

In any case, we don't really _need_ to consider sharing right now.
gcc can start slow, and import and convert to use gnulib modules 
incrementally, instead of having it import all the modules
gdb is importing from the get go.

Thanks,
Pedro Alves