This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On 23 June 2016 at 18:02, Pedro Alves <> wrote:
> 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.

AFAICT, the only "utilities" found in libiberty not appropriate for
gnulib is the demangler. That would be more appropriate for a
libdemangler library shared among all gnutools.

Moving all gnutools to a single git/svn repository that can still be
built piece-wise would help sharing gnulib and other useful libraries.
If LLVM can do it, there is no reason why gnutools can't. And they
have shown that it helps code reuse and modular design. All the manual
syncing between gnu projects is a waste of time.

> 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.

Nevertheless, it would be good to remove from the gcc's libiberty any
file/function not used by any GNU project.

Moreover, does it make sense that GCC remains the master copy if GCC
manages to remove every use of libiberty except the demangler?



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]