Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: Joel Brobecker <brobecker@adacore.com>, Yao Qi <yao@codesourcery.com>
Subject: Re: Include dir intl when building libcommon.a for gdb
Date: Wed, 02 Mar 2011 12:44:00 -0000	[thread overview]
Message-ID: <201103021243.58226.pedro@codesourcery.com> (raw)
In-Reply-To: <20110302121407.GO30306@adacore.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


  parent reply	other threads:[~2011-03-02 12:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-01  6:22 Yao Qi
2011-03-02 12:14 ` Joel Brobecker
2011-03-02 12:34   ` Kai Tietz
2011-03-04  5:55     ` Joel Brobecker
2011-03-02 12:44   ` Pedro Alves [this message]
2011-03-04  5:46     ` Joel Brobecker
2011-03-02 13:12   ` Mark Kettenis
2011-03-02 14:46   ` Yao Qi
2011-03-02 15:32     ` Pedro Alves
2011-03-03  3:15       ` Yao Qi
2011-03-03  5:40         ` Yao Qi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201103021243.58226.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=yao@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox