This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]