This is the mail archive of the
mailing list for the GCC project.
Re: Should we import gnulib under gcc/ or at the top-level like libiberty?
- From: Pedro Alves <palves at redhat dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, ayush goel <ayushgoel1610 at gmail dot com>, gcc at gcc dot gnu dot org
- Cc: nd at arm dot com, Manuel LÃpez-IbÃÃez <lopezibanez at gmail dot com>, Joseph Myers <joseph at codesourcery dot com>
- Date: Thu, 23 Jun 2016 18:02:33 +0100
- Subject: Re: Should we import gnulib under gcc/ or at the top-level like libiberty?
- Authentication-results: sourceware.org; auth=none
- References: <etPan dot 576ad632 dot 63dc2d3 dot fa at Ayushs-MacBook-Pro dot local> <52bf0980-635e-3784-fa55-5157894dd6b8 at redhat dot com> <576BF822 dot 3060802 at arm 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.