Re: [rfa/rfc] Build libcommon.a for gdb and gdbserver

[Pedro Alves <pedro@codesourcery.com>]

On Friday 28 January 2011 14:53:46, Tom Tromey wrote:
> Tom> Another idea would be to just have gdb/configure, but have a special
> Tom> Makefile target that only builds gdbserver.  Then all the configury
> Tom> would be unified; maybe this is the best option, for that reason.
> 
> Yao> I thought of this, but it makes gdb/configure in mess when we move
> Yao> everything to gdb/configure.  Finally, IMO, it is better to create
> Yao> separate Makefile.in/configure.ac in common/, whic scales well when we
> Yao> move more files to common/ later.
> 
> I think gdb/configure is already pretty messy.  It is more than 2000
> lines of code.  A few more for gdbserver aren't going to hurt much, IMO.

As I said before, gdbserver is buildable without building gdb, even
for targets that can't build gdb.  How would you make it work?

> The problem I have with adding another configure script is that
> presumably it must arrive at all the same conclusions as both gdb and
> gdbserver's configure scripts.  That means either maintaining things in
> parallel -- which will be fragile -- or putting a bunch of code into
> shared .m4 files.  But then... why run that same code multiple times,
> when we can just do it once?
> 
> Yao> 3. Including different headers when building libcommon.a for gdb and
> Yao> gdbserver.
> 
> I don't understand this.  I didn't see it in the patch.

Many of the core structures and defines aren't shared yet between
gdb and gdbserver.  gdb has defs.h, and gdbserver has server.h.
Ideally we'd pull the really common stuff into some header
under common/.  As is, there are incompatibilities.  Take a 
look at the top of common/signals.c, for example.

This is one of the reasons that I want to forbit gdb/common/ files
from including things from gdb/.  For the local patches we 
have that move stuff into gdb/common/ (independent effort from
Yao's), we added an #ifdef GDBSERVER then #error in gdb/defs.h
to catch that at compile time.

(Before Yao came along, my plan was to clean up these
header issues before considering building a common library.)

I think I'd now pushed all the dependencies those
said patches that move stuff into common relied on.  I'll
see if we can now get them pushed sooner than later.

> 
> Yao> 4  Building libcommon.a for gdb and gdbserver respectively.
> 
> This seems to mean that we must build libcommon twice.  I don't
> understand that -- what is the benefit, versus having a single library?

See above.  It's not possible currently.  gdb/common/ includes 
headers from gdb/ when built for gdb, and headers from gdbserver/
when built for gdbserver.

-- 
Pedro Alves