This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Problem about insight rename patch
- From: Keith Seitz <keiths at redhat dot com>
- To: Pierre Muller <muller at cerbere dot u-strasbg dot fr>
- Cc: Andrew Cagney <ac131313 at redhat dot com>, <gdb-patches at sources dot redhat dot com>, <insight at sources dot redhat dot com>
- Date: Thu, 3 Oct 2002 08:57:27 -0700 (PDT)
- Subject: Re: Problem about insight rename patch
On Thu, 3 Oct 2002, Pierre Muller wrote:
> But that patch also add
> _initialize_gdbtk
> function reference.
Yes, that's true, and if I ever get ten minutes to do this (and I can
remember!), I'll submit a patch to fix this.
However, it's not quite as critical a bug IMO as long as no one is linking
against a libgdb.a built in an insight-enabled build. AFAIK, libgdb.a
isn't very useful when insight is enabled (except to insight, of course).
> Moreover this means that gtk is still
> included in the compilation of gdb executable,
> which seem to be the absolute contrary of the aim
> of separating gdb and insight, no?
[s/gdbtk/gtk/ ?] Yes, this is still true. And if you were to run "gdb -w",
insight would show up. Contrary to the purpose of separating the two? Yes,
really it is, but we've got to start somewhere. Too often I've found that
ideas/patches are rejected because they don't implement everything needed.
Some people (not all) are not satisfied by the piecemeal approach: nibble
a little here, check it in. Maybe someone else will nibble at it.
Eventually, the problem gets solved. Maybe not optimally, but it gets
solved.
> Basically removing
> _initialize_gdbtk from init.c
> does not prevent gdb from compiling,
> so the only reason why I didn't send a patch proposal
> is that I don't know the correct way of fixing it?
> Maybe separate init.c
> into init.c and insight-init.c?
> But there might be better solutions?
I believe the proper way to do this (Andrew/others will step in and tell
me if I'm barking up the wrong perverbial tree) is to create an
init_chain, which holds callbacks to be made for initialization.
insight-main.c could register _initialize_gdbtk to this chain and top.c
would then call it when it was doing initializations. My initial plan was
to submit a patch to do just this. Eventually we could investigate getting
other initializations registered in main (or we could simple keep init.c).
Or we could just create a new initialize_hook (yich) which main could set
to get _initialize_gdbtk to run. Or we could just integrate
_initialize_gdbtk into main(), or ...
Keith