From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32531 invoked by alias); 5 Sep 2003 15:06:36 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 32500 invoked from network); 5 Sep 2003 15:06:34 -0000 Received: from unknown (HELO garm.central.cmich.local) (141.209.15.48) by sources.redhat.com with SMTP; 5 Sep 2003 15:06:34 -0000 Received: from leon.phy.cmich.edu ([141.209.165.20]) by egate1.central.cmich.local with Microsoft SMTPSVC(5.0.2195.5329); Fri, 5 Sep 2003 11:06:05 -0400 Received: from localhost (unknown [127.0.0.1]) by leon.phy.cmich.edu (Postfix) with ESMTP id 445D870022; Fri, 5 Sep 2003 11:06:01 -0400 (EDT) Date: Fri, 05 Sep 2003 15:51:00 -0000 From: Eric McDonald To: Hans Ronne Cc: xconq7@sources.redhat.com, Juergen Ruehle Subject: Re: Tcl/Tk Interface Unification (was Re: New Xconq Windows Executable) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 05 Sep 2003 15:06:05.0807 (UTC) FILETIME=[3ABF4FF0:01C373BF] X-SW-Source: 2003/txt/msg00405.txt.bz2 Hi Hans, Juergen, Juergen, I applied your patch and everything seemed fine (as expected). I haven't committed the changes yet because I am experimenting with building a completely statically-linked Xconq app. I built the Sourceforge distro of Tcl/Tk under Windows (had to use the MinGW compiler though), and am linking against that. On Fri, 5 Sep 2003, Hans Ronne wrote: > The advantage of these rearrangements are two-fold. First, it will be > easier keep track of what files belong to what interfaces. Second, one > would no longer need hacks supporting several different interfaces within > the same source file, as is now the case for xconq.c. The only disadvantage > is the slight code duplication. However, I think we can live with this. The > entire xconq.c is only 241 lines including the comments. I am not particularly keen on the idea of maintaining two separate sources that are partially duplicate. Perhaps we can could do something like: #include "x11/xconq-common.c" or #include "platform/unix/xconq-common.c" in both tkunix.c and sdlunix.c ...? Even though we would possibly be including function definitions in multiple places, we would not run into link-time troubles, because only one of the interfaces is being built. Thanks, Eric