On 23 June 2016 at 18:02, Pedro Alves <pal...@redhat.com> 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? Cheers, Manuel.
