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