Re: Problem about insight rename patch

[Andrew Cagney <ac131313@redhat.com>]

>> 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 ...

Any / all of the above.

Similar issues arise with MI, TUI and CLI.  The way init.c is created 
could do with a re-think.  Fortunatly it isn't causing any immediate pain.

One thing though, I think more of the files should always be added to 
libgdb.a.  I can't think of a reason for not including MI or CLI files 
in the archive by default.

Andrew