From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6860 invoked by alias); 21 Oct 2002 19:08:48 -0000 Mailing-List: contact insight-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sources.redhat.com Received: (qmail 6713 invoked from network); 21 Oct 2002 19:08:44 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 21 Oct 2002 19:08:44 -0000 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by touchme.toronto.redhat.com (Postfix) with ESMTP id D684B8000F1; Mon, 21 Oct 2002 15:08:42 -0400 (EDT) Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 3EF273EE6; Mon, 21 Oct 2002 14:00:16 -0400 (EDT) Message-ID: <3DB440B0.70003@redhat.com> Date: Mon, 21 Oct 2002 12:08:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Seitz Cc: Pierre Muller , gdb-patches@sources.redhat.com, insight@sources.redhat.com Subject: Re: Problem about insight rename patch References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-q4/txt/msg00051.txt.bz2 >> 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