Date: Wed, 10 Oct 2001 20:43:57 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: tim DOT van DOT holder AT pandora DOT be Message-Id: <7263-Wed10Oct2001204357+0200-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9 CC: djgpp-workers AT delorie DOT com In-reply-to: <000301c151ab$26da9040$6ff8e0d5@pandora.be> (tim DOT van DOT holder AT pandora DOT be) Subject: Re: First round of XP tests References: <000301c151ab$26da9040$6ff8e0d5 AT pandora DOT be> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: "Tim Van Holder" > Date: Wed, 10 Oct 2001 18:46:43 +0200 > > > > * emacs 21.0.97 also configured and built just fine > > > (except for some lib-src/ programs that needed > > > sockets.h). > > > > That's because you didn't use config.bat to configure Emacs. The > > DJGPP port of Emacs doesn't use the configure script. > > Still, that only takes a minor addition to configure.ac > and then configure works fine. I just prefer using configure > over config.bat, even if that means I need to modify configure.ac; It's a free world and Free Software. You can do whatever you see fit, but please don't come back crying that something is broken, because the DJGPP build doesn't support the configure script. (It does so on purpose, btw: Emacs is such a basic development tool that it makes sense to try to build it with only a small number of basic tools, to avoid the chicken-and-egg problem. I think we've been through this discussion more than once in the past.) > using a batch file just feels more hackish. That's hardly a nice thing to say to someone who put a great deal of effort into getting that batch file as reliable and portable as possible. > > There's no need: if HOME is not defined, Emacs pushes a default > > definition into the environment during startup, so HOME is always > > defined in an Emacs session. (That code goes back to when Morten > > worked on the port.) > > Yes, but bash will also sometimes complain during config.status that > HOME is not set. And $DJDIR seems a natural value for HOME, unless > the user sets it differently. If djgpp.env sets HOME, every program that a DJGPP program invokes will inherit that setting. Since many non-DJGPP programs could react to that in surprising ways, I don't think we should define HOME unless it's absolutely required. Emacs does that because many Emacs packages will crash and burn without HOME, and because it needs some reasonable place to look for the _emacs startup file. If you (and Mark) think that Bash needs HOME as well, let's define HOME in the [bash] section. But doing so globally would be IMHO a mistake; in particular, it will instantly break almost every Emacs installation out there, since Emacs defines HOME to point to its installation directory (if the user didn't define otherwise). > > > * find seems to be case sensitive even without > > > FNCASE=y. Running "find -name '*.cvs'" yielded no > > > results, but "find -name '*.CVS'" did. > > > > What files did it find? Depending on the actual file names, this > > might or might not be expected behavior, because without FNCASE=y, > > DJGPP programs try to preserve letter-case in file names where it > > ``matters''. > > find '*.cvs' returns nothing, find '*.CVS' returns the list of > '_.CVS' files in the tree. That sounds like a bug. > Since the filesystem is case insensitive, name comparisons done by > find should be case insensitive as well. No, `find' is case-sensitive, and the DJGPP port tries to behave the same, as much as this is possible. > find '*.cvs' returns > > ./z/z1/!.cvs > ./_.cvs > > on WinME, but nothing under WinXP; find -name '*.CVS' returns > > ./y/foo.CVS You may have found another XP bug; perhaps some other LFN-related system call is botched. Please consider looking into this. > I can see a few cases where being so strict might be useful > (e.g. a find -name '*.S' might be intended to only return > asm-with-cpp files), but since the filesystem doesn't care, I > don't we should either. Why should `find' not care about the difference between *.s and *.S, when GCC and Make do? Don't you think it would be terribly confusing? > Still, if 2K and XP return different values, that could be used to > distinguish them for W2K-only/WXP-only patches (AFAIK, currently > those simply check for 0x532). Alas, NT/W2K/XP don't let DOS programs access the Windows version. The function of Int 2Fh that's supposed to report the Windows version, and which works on Windows 3.X, 9X, and ME, simply fails on NT and its family, as if Windows were not there. In other words, Windows NT and its descendants want DOS programs to think they are running on plain DOS 5.