Re: Fix in-src-tree builds by making gdbserver/gnulib/ a separate library (a la libiberty, etc.), and adding ACX_CONFIGURE_DIR.

[Pedro Alves <palves at redhat dot com>]

On 04/16/2012 09:15 PM, Doug Evans wrote:

> On Mon, Apr 16, 2012 at 1:01 PM, Tom Tromey <tromey@redhat.com> wrote:
>> > Pedro> The Real, Proper, Ideal fix for this, IMO, is to make gdbserver a
>> > Pedro> proper src top level project/directory, on the same level as GDB,
>> > Pedro> and make the new gnulib "library" a top level project as well, on
>> > Pedro> the same level as GDB and libiberty.  Then, the top level
>> > Pedro> configure would only try to build the gnulib directory once, by
>> > Pedro> design, and would build both gdb and gdbserver if both are
>> > Pedro> supported by the host, or only gdb if building a cross debugger.
>> >
>> > Yeah, this would be good too; but I understand why you wouldn't want to
>> > do it :-)
> gdbserver is a target program, so if one wanted a "one tree" build,
> one would need to configure gnulib for both host and target (when host
> != target).


Or, we could instead consider gdbserver a host program.  If you want
to build a gdbserver for your target foo, you'd build it from the
top-level with --host=foo.  Thus to build a cross debugger + gdbserver
for the target, you'd need to configure twice (once for gdb, and once
for the target gdbserver).  But that's no different than what we have
today.

> If there's no disagreement that moving gdbserver to the top level is
> the right thing to do (I think it is) then I think time spent doing
> something different is ultimately time not well used.


This first step is less intrusive, and we can test the new gnulib wrapper
library scheme this way without a top level move.  That much isn't lost,
and is IMO, the largest change here.  Plus, it's already written; it
only took me a few hours.  :-)

> If gcc can move libgcc to the top level, we should be able to move gdbserver.


Yeah.

-- 
Pedro Alves