Re: Include dir intl when building libcommon.a for gdb

[Pedro Alves <pedro at codesourcery dot com>]

On Wednesday 02 March 2011 12:14:07, Joel Brobecker wrote:
> This definitely makes me rethink the way we approached the problem.
> By taking what we have now, and moving it to common/, we drag some
> dependencies which I think we do not want. I think we should either
> strive to remove these dependencies as fast as we can, or use an
> approach where we go the other way: Start with the foundations, and
> then implement the things we are trying to move to common/ using
> that foundation.  For instance, defs.h versus server.h.  It's tough
> right now, because defs has more than just definitions. We could
> isolate the part that provides the common non-GDB-specific definitions
> into a common/common-defs.

Thank you.  +1.  I said something like that from the beginning,
but I didn't imagine that a configure&make under common/ sooner
than later would actually make our lifes complicated.  I have
since learned, and I believe it was a wrong step to make.
I'd much rather we were spending energy on that foundation rather
than on the build, when we have only a handful of files to share
at this time.

> In the meantime, one proposed easy way out that doesn't destroy
> all the work that has been done so far is to add all the -I
> directories regardless of who we build libcommon for.  I think
> it makes sense from a conceptual point of view, and it will also
> help us avoid maintaining 2 lists. But maybe it doesn't work for
> practical reasons.

gdbserver does not depend on bfd.  It's wrong to leave it in
the include path.  gdbserver is not using gnulib either (memmem.o hack
doesn't count), so there goes another include path that
should not be present on gdbserver's common/ build, and should be on
gdb's common/ build, but isn't at present, I think.  That's a
bug, and it will show its face as soon as something under
common/ needs to include a gnulib header on some host (it may
already, haven't checked, linux hosts doesn't need any at present).

-- 
Pedro Alves