On Mon, Mar 19, 2012 at 9:09 AM, Doug Evans <d...@google.com> wrote: > On Thu, Mar 15, 2012 at 12:02 PM, Tom Tromey <tro...@redhat.com> wrote: >>>>>>> "DJ" == DJ Delorie <d...@redhat.com> writes: >> >> Tom> Finally, there is already stuff in libiberty not related to >> Tom> portability. E.g., hashtab or the demangler. >> >> DJ> Yeah, I know, hence my "Should I give up that premise?" >> >> Yeah. >> >> I am not sure there will ever be enough shared code to warrant a new >> library, particularly because adding a new library is so expensive -- >> not just the configury stuff but also adding it to the link lines in the >> Makefiles of all the tools that might need it. >> >> I suppose if I had my wish list implemented here, it would be to remove >> the portability stuff from libiberty in favor of gnulib, and keep >> libiberty as a higher-level library. > > That won't really fix libiberty being an ever growing kitchen sink. > > How hard would it really be to make it easier to add new libraries? > It's not like we're expecting 100. > But given the pushback for even one new library, I think we're > unnecessarily slowing ourselves down.
btw, While I like using gnulib more, do we know it will necessarily always solve portability problems in a timely manner? I wouldn't mind keeping libiberty as a fallback. Plus, some of the complexity of libiberty is supporting all of $build,$host,$target in one build. The utilities I think you're thinking of adding (or at least the utilities I've come across as wanting to add to a more useful location) are just for the tools (i.e. $host). Putting them in libiberty doesn't "feel right".
