X-Spam-Check-By:	sourceware.org
Message-ID:	<4625DB90.6000001@cwilson.fastmail.fm>
Date:	Wed, 18 Apr 2007 04:49:20 -0400
From:	Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent:	Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: .exe magic
References:	<46254976 DOT 4000308 AT cygwin DOT com> <loom DOT 20070418T010849-170 AT post DOT gmane DOT org>
In-Reply-To:	<loom.20070418T010849-170@post.gmane.org>
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

Eric Blake wrote:
> Interesting thought.  But it is more than just cygwin 1.7.0 that would have to 
> be changed; we would also need a new release of gcc that no longer added an 
> automatic .exe to files as they are compiled.  And there might be some severe 
> repurcussions in automake/autoconf where they currently are coded to handle 
> $(EXEEXT) all over the place, if they do it based on hostname rather than on 
> what the default gcc output is.  I would have to remove some of the .exe magic 
> I've added in coreutils (but it would mean I'm closer to an upstream image).

Um, some people actually launch cygwin tools from outside a shell, via 
shortcuts.  Like, say, rxvt, or run, or bash.  I think the windows 
subsystem still requires known extensions in order to start new 
processes (%PATHEXT%=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH)

And even if that were not a problem, I still suspect that making a 
drastic change like that will have many far-reaching, non-obvious, and 
deleterious effects.  Here's one of the top of my head (and not nearly 
the most significant): right now cygwin and mingw benefit from each 
other; there is a lot of cross-pollination in the ports of various 
packages to "windows" that we get to leverage.  Making a change like 
this would IMO have a net negative effect on this kind of resource 
multiplication we currently benefit from.

The current .exe behavior has benefited from many years of tweaking and 
fine-tuning, across many different packages (cygwin, gcc, gdb, binutils, 
automake, autoconf, libtool, bash, coreutils, ...) to work together to 
give the current, mostly coherent, least-surprise behavior we enjoy 
today.  I strongly caution against making a drastic change like this at 
all, and ESPECIALLY against changing the default behavior of tools like 
gcc, bash, and coreutils.

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -