Mail Archives: djgpp-workers/2001/01/14/13:28:53
> From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
> Date: Sun, 14 Jan 2001 13:56:51 +0100
>
> > Most packages which support DJGPP in the official distribution use the
> > configure script (Emacs and Make are the notable exceptions), so there's
> > no Makefile.dj2 to hack. If the configure script and Makefile.in don't
> > DTRT, you are screwed.
> Not really, you can just add AC_EXEEXT to configure.in and @EXEEXT@ to
> Makefile.in and it will continue to DTRT on all platforms.
> But then we get into the same discussion we had with gettext: should
> maintainers of DJGPP packages be required to have autoconf/automake. My
> feelings on this are a definite YES, but most others on this list seem
> to disagree with me (mostly because automake/aclocal requires perl, which
> is a non-trivial package).
Perl is not the only issue.
I think that a package which supports DJGPP should be able to be built
out of the box, exactly like on Unix. Since Unix and GNU/Linux users
are not required to have Autoconf, I think DJGPP users should not be
required to have it as well. They should be able to run the configure
script and then say "make". That's what INSTALL says in each package.
> > I think libc will either invoke COMMAND.COM to run these ``programs'' or
> > pass them to DOS, with very sad results (since COMMAND.COM and DOS will
> > happily run _anything_). You can try it and see what happens.
> I thought system actually checked a file was executable. If it doesn't,
> Anything May Happen(tm).
The library does check if the file is any of the executables it knows
about. But if all the tests fail, it finally punts and lets DOS
handle that.
> > Anyway, even if libc refuses to run the program, the command in Makefile
> > will fail, which isn't what we want.
> I thought system()/spawn() would skip foo if it wasn't executable, and then
> find foo.exe and run that.
No, the current code doesn't skip foo. It only goes to foo.exe if foo
was not found at all. The only exception is if foo is a directory.
> > If we don't want to accept the consequences of getting rid of the
> > unstubified COFF executables, and don't have resources to fix all the
> > popular packages out there that rely on them, we had better not make
> > this change in ld. A bit of disk waste hurts much less than broken
> > packages, especially since "make clean" removes all that junk.
> But then make clean wouldn't remove foo.exe, as it doesn't know about .exe.
That's right, it doesn't remove foo.exe, at least in some (many?)
cases. However, as long as the target in the Makefile is called
`foo', Make doesn't care, because it doesn't know that foo.exe is
created by the rule. So the existence of foo.exe doesn't do any harm
except taking up some disk space.
> I think adjusting ld would be a good TEMPORARY solution; DJGPP package
> maintainers should submit patches to the GNU maintainers for packages that
> don't use automake or don't use AC_EXEEXT properly.
The problem is that the ``DJGPP package maintainers'' aren't exactly
an army: I probably can count them on fingers of one hand.
> Makefiles will have a problem (they'll try to rebuild each executable when
> you type make), but that's more of a nuisance than real breakage.
This nuisance might be not so small, depending on the package (e.g.,
try Emacs or Web2c).
- Raw text -