Eric Blake wrote: > Larry Hall (Cygwin <reply-to-list-only-lh <at> cygwin.com> writes: > >> Here's a naive thought. See if it makes any sense. We have lots of >> complicated logic to try to transparently handle ".exe" extensions. >> We have ".exe" extensions because Windows 9x/Me requires it to execute >> binaries. For the upcoming Cygwin 1.7 release (date TBD), we're dropping >> support for Windows 9x/Me. Does it follow that complex ".exe" logic >> could be dropped from 1.7 as a result? > > 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).
Seems manageable but that's also a naive statement. ;-) I know next to nothing of the complexities of automake/autoconf. >> I realize this would be a hard break with the 1.5 Cygwin series since it >> would force all Cygwin packages to remove the ".exe" extensions, thereby >> excluding 9x/Me users from these package updates - assuming they would >> otherwise be compatible - even though the Cygwin package would not be. But >> there has to be something worse about it than just this. I'm mean, this >> has to be a real stupid idea... > > I think it has merit. But there are some caveats. It will BREAK libtool, > which currently RELIES on having ./foo and ./foo.exe in the same directory, > where ./foo.exe is a binary that satisfies the make dependency for > foo$(EXEEXT) > and invokes ./foo, and where ./foo is a script that invokes the > real ./.libs/foo.exe with the correct environment variables set. And you are > correct that if we made the no-.exe extension for cygwin-created executables > mandatory, that every packager with binaries would have to update their > package > to the new 1.7.0 scheme. Forgot about libtool and it's reliance on ./foo and ./foo.exe. :-( > On the other hand, this would be a good idea to prune away any unmaintained > packages. And if we go this way, we could introduce any other binary > incompatible change that makes cygwin1.dll more efficient but requires the > recompile (such as the change from 1.3.x to 1.5.0 to introduce 64-bit file > offsets). True, though strictly speaking, this change shouldn't require a recompile of most packages. A simple renaming should suffice in most cases. > I don't know how likely it is to happen though; I'll let cgf and Corinna > comment on that. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _____________________________________________________________________ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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/
