Robert Collins wrote:
On Mon, 2003-06-09 at 15:09, ${john}$ wrote:The .exe suffix screws things up. A lot of packages identify the target as Cygwin, and your executables then get that extension. Then the build fails because a filename is hard-coded in a makefile somewhere (debian/rules, for example). If you ask me, the .exe has to go. No other Debian platform uses an extension for exectuables, and you're not going to persuade everyone to change their packages to accommodate it. So I guess that means fixing config.guess, so it can identify Debian win32 systems and act appropriately; then and rebuilding gcc. Something like that.Don't do this. The .exe suffix should stay. There have been many long discussions on this elsewhere, I won't repeat them now.
Your case is so strong that you're not going to bother telling anybody what it is. Well gee, I'm convinced.
My argument is simple -- I can't see the port ever happening with the .exe extension. Based on the packages I've built, I'd say that suffix will breaks hundreds of makefiles in Debian packages. And I'm not talking about automatically generated files that can be fixed by tweaking a tool or batch editing -- AFAICS, most of these would need to be fixed by hand and accepted by maintainers and/or upstreams (varies). So anyone who thinks .exe is practicable first needs to explain which magic fairy is going to arrange this,
Then there's the filename problem -- normally, Windows doesn't do certain characters, for example colons. You'll hit this one building packages for perl-doc, defoma, spamassassin, countless Perl modules, etc. Apparently you can turn on POSIX compliance, which sounds like the way to go. In a previous discussion I think people suggested patching newlib to substitute another character, but I don't like the idea of changing filenames. It just opens up more potential problems (eg breaking hard-coded filenames in scripts and configs, risks clashes with other files in Debian, etc).Well, IIRC : isn't in the POSIX portable filename list anyway
But it is part of NTFS's POSIX namespace (as is every Unicode character except / and null) which means you may use it in a filename. (Whether any bit of Windows API will oblige you in this respect is another matter.)
[...]
and AFAIK : will still refer to alternate streams on NT kernels.
It certainly does if you use it as part of a conventional filename. I had assumed that could be circumvented, but perhaps not.
Looking back at was suggested on this list before, I note that it was not substitution, but escaping and unescaping of problem-characters. In practice, I'd say that's as good as storing the names correctly. (The escaping would cause filenames would appear wrong from non-Cygwin apps; but said apps wouldn't be able to use them if they were named correctly anyway.) That system should work for Win9x too, although nobody should think for one minute I give a damn about whether this port ultimately does.
While we're talking file names, I'll point out that I have here a box with a moderate number of packages installed, and there are...
, | john@termite:~$ dpkg -S '*' | sed "s/^[^:]*: //" | tr A-Z a-z \ | > | sort | uniq -d | wc -l | 161 `...161 package files with names that differ only by capitalisation. Another little issue that people might want to consider, given that VFAT and the win32 and DOS NTFS namespaces preserve case but are not case sensitive.
-- John Ineson