Mail Archives: djgpp-workers/2001/10/10/14:45:17
> From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
> 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;
<Shrug> 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.
- Raw text -