From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15439 invoked by alias); 15 Jul 2002 07:28:00 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 15393 invoked from network); 15 Jul 2002 07:27:57 -0000 Received: from unknown (HELO mta7.pltn13.pbi.net) (64.164.98.8) by sources.redhat.com with SMTP; 15 Jul 2002 07:27:57 -0000 Received: from modrick ([66.120.11.181]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GZA009Y74QKQX@mta7.pltn13.pbi.net> for gdb-patches@sources.redhat.com; Mon, 15 Jul 2002 00:27:56 -0700 (PDT) Date: Mon, 15 Jul 2002 03:06:00 -0000 From: Mo DeJong Subject: Re: [patch] Fix expect build under cygwin + Tcl/Tk 8.3 To: gdb-patches@sources.redhat.com Message-id: <20020715002731.55d20136.supermo@bayarea.net> Organization: House of Mirth MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-SW-Source: 2002-07/txt/msg00316.txt.bz2 Hello. I am just checking back on a patch I sent in: http://sources.redhat.com/ml/gdb-patches/2002-05/msg00621.html It got one response: http://sources.redhat.com/ml/gdb-patches/2002-05/msg00654.html > >The current CVS version of expect does not build correctly under > >Cygwin. The root of the problem is that expect is searching for a > >tclConfig.sh file in tcl/unix when it should be looking in tcl/win. > >The following patch fixes the problem by updating the m4 macros used by > >the expect build. > AFAIK, expect shouldn't be using the win version of anything. It is > supposed to be using a UNIX-only implementation of tcl. > cgf I guess it would have helped if I had included the more detailed description from my earlier post to the insight list: "This patch will get the configure script to pickup the tclConfig.sh out of the tcl/win subdirectory instead of the fake one Tcl is currently generating in the tcl/unix subdirectory. One possible objection to this patch would be that a tclConfig.sh should be created in the tcl/cygwin subdirectory and then found there before checking tcl/win. That may be the "more correct" thing to do, but this patch just tries to do the "less wrong" thing since it is the minimal change that should get everything working again." The other way to fix the problem would be to create a new tclConfig.sh file in the tcl/cygwin sub and populate it with needed values and then add support for this new subdirectory to any of the Tcl extensions that needed it. That could end up being quite a bit of work. In the end, I don't think it would matter since expect seems to ignore the contents of the tclConfig.sh file, it just wants it to be there. Also, the configure scripts in the expect subdir seem to be way out of sync with the configures in the other extensions, so it seems like a big rewrite would be needed to actually use the contents of the tclConfig.sh file. So, my point is that I think my patch should be applied since it fixes the problem. It might be the most minimal fix, but I don't see how that is any worse than what we have now. Currently, the Windows version of Tcl/Tk/Itcl will not build because Tcl incorrectly emits a unix/tclConfig.sh file just to make expect happy (and that hoses Itcl). cheers Mo DeJong