.exe magic

Charles Wilson cygwin@cwilson.fastmail.fm
Wed Apr 18 08:50:00 GMT 2007


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/



More information about the Cygwin mailing list