Mail Archives: djgpp/2011/12/01/16:15:16
Hi,
On Dec 1, 6:46 am, tm <thomas DOT mer DOT DOT DOT AT gmx DOT at> wrote:
> On 1 Dez., 02:14, Rugxulo <rugx DOT DOT DOT AT gmail DOT com> wrote:
>
> AFAICS only one redirection (the one to get the C compiler version)
> has problems. Other redirections (e.g.: echo into "version.h") don't
> have problems. Since I plan to determine the C compiler version in
> "chkccomp.c" (instead of in the makefile) this could work without
> REDIR.COM.
That's fine. Just keep in mind that (DJGPP's) REDIR.EXE is good for
redirecting stderr (a la "2>") and also timing execution ("-t") since
most DOS shells "traditionally" didn't support such features.
> > Honestly, the whole '\\\\' part was giving a (harmless??) warning, so
> > I'm not entirely sure how to fix that. Perhaps '\\\\\' [sic, five!],
> > but maybe not. Eli Z., are you reading this? (he's the expert!) ;-)
>
> Ok, I will use
>
> echo "#define PATH_DELIMITER 92 /* backslash (ASCII) */" >> version.h
>
> instead. Hopefully the quotes around the string beware us from
> problems with the C comment. Does the echo command above (issued
> from a makefile) write
>
> #define PATH_DELIMITER 92 /* backslash (ASCII) */
>
> into the file "version.h"?
Tested that briefly here (Make 3.81) under DOSEMU, seems to work fine.
> > > This way the check for the C compiler version is done inside the
> > > program chkccomp.c with a system() call. But there is still
> > > the command
>
> > > echo "#define GET_CC_VERSION_INFO \"$(GET_CC_VERSION_INFO)\"" >>
> > > version.h
>
> > (confusing without testing it)
>
> Maybe I should just send my current version of "mk_djgpp.mak" by
> mail.
Probably, heh, sorry for any inconvenience, it's just a lot of
patching can be confusing.
> > > in "mk_djgpp.mak". Hopefully it does not create problems. Currently
> > > I plan to release two versions of "mk_djgpp.mak". One which works
> > > for you (commands are executed by bash), which will probably keep
> > > the name "mk_djgpp.mak" and one which works for me (commands are
> > > executed by cmd.exe/command.com), which would get a new name like
> > > "mk_djgp2.mak". The "mk_djgp2.mak" makefile will hopefully help
> > > people, who did not install the DJGPP bash package.
>
> > I have no intention of requiring Bash. I'd rather do without,
> > honestly. Don't feel obligated to support that. It'd be best if it
> > didn't need it and "just worked" in CMD or COMMAND.COM.
>
> So your DJGPP installation does not include bash. I thought that
> your make utility executes commands in the makefile with bash. At
> least executing echo from a makefile seems to remove quotes ("),
> unless they are escaped with \" .
Bash is a POSIX shell. DOS is not POSIX. Make also doesn't
(necessarily) require Bash at all. DJGPP's libc, Make, and Bash all
have various workarounds (kludges?) to avoid certain limitations or
enable POSIX-specific features that otherwise wouldn't work.
I'm just saying, I don't use Bash when I don't need it. Sure, for ./
configure it's needed, but that's not a DOS feature, that's GNU's
doing (and it's a horrible kludge, barely works!). I don't need a Bash
shell to run DOS or DJGPP. GCC in DOS only truly needs (as minimum)
libc (djdev204.zip), as + ld (bnu2211b.zip), and gcc (gcc462b.zip).
Make did indeed (IIRC) remove quotes when running under DOS, with or
without Bash! I'm not sure I remember anymore, it may have changed
between 3.79.1 and 3.81. Something like SHELL=/dev/env/DJDIR/bin/
bash.exe isn't set by default anymore or some such, dunno. It's very
confusing, and we have no dedicated Bash, or maybe even Make,
maintainer for DJGPP. Eli Z. might? know or care, but he's probably
ultra busy like the others, I presume.
Long story short: it might honestly just be easier for you (and me?)
to stabilize on one single version of GCC, BinUtils, DJDEV, Make,
(plus CoreUtils of course), etc. Mixing and matching isn't working too
well.
> > But the console doesn't pause when full, sadly. Perhaps you should
> > pipe it to "more" or "less" or whatever. But nah, I still say an
> > output file would be better (IMHO).
>
> In the first post you were able to send the whole output of
> "chk_all.sd7". Are you referring to the output of "hi comp chkbig"
> and "hi comp chkset"?
If it's pointed to stdout, simple redirection works fine (though, due
to limitations, piping doesn't show any results until *everything*
finishes). Redirecting from stderr is a bit tricker depending on which
tools you use. FreeDOS does have a device driver that lets you ">more
$" without any intermediate files, so maybe I should've used that. But
you can't scroll back up or anything (like Linux, FreeBSD), so hence I
almost prefer a static output file.
I mean, there are tools to extend text resolution to pretty big in
pure DOS (80x50, 132x60, and several variations, etc.), but I'm fairly
certain Seed7 errors would exceed it no matter what (unless something
is patched, heh, and I don't claim to know anything about IEEE
floating point, and surely I don't think most DOSes will ever support
write-only files).
- Raw text -