This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: introduce common.m4
- From: Pedro Alves <palves at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 26 Jul 2013 16:34:10 +0100
- Subject: Re: RFC: introduce common.m4
- References: <871u9zomzd dot fsf at fleche dot redhat dot com> <51782A71 dot 7030305 at redhat dot com> <87obd3n4c8 dot fsf at fleche dot redhat dot com> <51782CC6 dot 9040008 at redhat dot com> <871u9zn0wa dot fsf at fleche dot redhat dot com> <517ACB2C dot 2030006 at redhat dot com> <87vc425vue dot fsf at fleche dot redhat dot com>
On 07/22/2013 06:48 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
>
> [ old-ish thread... ]
>
> Pedro> IMO, it's a little better if each subdirectory treats the
> Pedro> others more as black boxes. gdb/ relying on common/'s
> Pedro> HAVE_FOO checks feels like gdb/ relying on common/'s
> Pedro> implementation details to me. But I don't want to impose.
>
> Yeah, I agree. When I refresh this patch I will do it this way.
>
> Lately I have been thinking that common and gdbserver should be
> top-level directories (after renaming "common" something more suitable).
> This would let us use libiberty in gdbserver while still preserving, I
> think, the ability to build gdbserver separately. Also it would let us
> treat "common" as a true library, not as the odd beast it is today.
Yeah, that crossed my mind before too. But, it's not really necessary
for libiberty in gdbserver, given we could use the same trick
we use for gnulib (ACX_CONFIGURE_DIR). With that in mind, such a
move seems more trouble than it's worth it to me, at least for now
as long as we're using cvs+modules.
> Perhaps gnulib would also have to be pushed up.
--
Pedro Alves