Mail Archives: djgpp/2011/12/01/08:00:17
On 1 Dez., 02:14, Rugxulo <rugx DOT DOT DOT AT gmail DOT com> wrote:
> On Nov 30, 5:01 pm, tm <thomas DOT mer DOT DOT DOT AT gmx DOT at> wrote:
> > When I use redir under XP it just writes
>
> > The Vdm Redirector is already loaded
>
> > and it does not redirect anything. I really have doubts to use
> > redir, as it seems to fail under Windows. Do you use an original
> > DOS redir or one from a DOS clone?
>
> Oops, this is a minor configuration error that I'd hoped wouldn't bite
> you. Long story short, you should put DJGPP\BIN first in your PATH
> (plus it's faster that way). I've thought before that "next" DJGPP (I
> can dream, can't I?) would fix some of the Windows issues by renaming
> or symlinking some things, e.g. djredir, djpatc, djupdat, etc.
>
> Long story short: Windows has its own (unrelated) REDIR.EXE in the
> path, but DJGPP's version (in your /bin/ directory) is what you want.
> Heck, perhaps we could rename DJGPP's to REDIR.COM. It should still
> work the same (famous last words).
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.
> > > > Escaping quotes is also done in other makefiles. In this makefiles
> > > > the argument to echo is a quoted string. Inspired by this I created
> > > > the following makefile:
>
> > > > ------------- begin mk_djgpp.mak ---------------
> > > > (snip)
> > > > ------------- end mk_djgpp.mak ---------------
>
> > > I guess I should give this a try and report back?
>
> > Yes, please.
>
> IIRC, it didn't quite work, but I think it was minor stuff. I'll have
> to try again (sadly, I know that's not a great answer).
>
> 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"?
> > 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.
> > 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 \" .
> > The advantage of make comes into effect, when a few source files are
> > changed, and make only compiles the changed files.
>
> Right, but when everything *requires* make and is so brittle and
> easily broken, it's just frustrating. Worse when lots of POSIX or
> Linux-specific stuff is used. Heck, I was trying something else
> earlier today and got weird errors. It's just frustrating, that's all.
> (And Make 3.82 has been out for a few months [though not for DJGPP]
> but has some weird bug or two. Strange how hard it is to stabilize.)
>
> It's fun when it works, painful when it doesn't.
Hopefully we soon come to the fun part with Seed7 compilation.
> > > > > > redir -eo hi chk_all | tee blah.txt
>
> > > > As explained elsewhere you can start every chkxxx.sd7 program
> > > > separately. Separate compilation of every chkxxx.sd7 programs is
> > > > also possible.
>
> > > Yes, I know, but "hi chk_all" is the official way, no?
>
> > Yes, but when "hi chk_all" shows errors it can be helpful to start
> > and compile chkxxx.sd7 programs separately.
>
> Yes. But I would prefer output written to file if it's bigger than two
> screens or so. Then it'd be easy to compare with md5sum or diff or
> whatever.
I see.
> 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"?
> > > > > But let me reiterate that "hi chkbig"
> > > > > and "hi chkset" both work fine. Honestly, all this fuss may be (only)
> > > > > over the compiled compiler, which I don't really "need", do I? An
> > > > > interpreter is good enough. ;-)
>
> > > > It would still be interesting to find out why compilation of
> > > > chkbig.sd7 and chkset.sd7 fails. I want to be sure that the Seed7
> > > > compiler is not the cause of the error.
>
> > > Honestly, surprisingly, I don't think it is. But there are a lot of
> > > little pieces and weird issues with various environmental things. So
> > > it's hard to isolate (and confusing, at least to me).
>
> > Ok, so I assume for now that the errors are not caused by the Seed7
> > compiler.
>
> Too few maintainers, not enough testers, too difficult to fix / patch
> things unless you know ten bazillion POSIX-y things. No, I don't think
> this is Seed7's fault, but there are obvious more than a few things
> stacked against us for building some such things, sadly. It takes hard
> work to fix. I just wish I wasn't so useless ....
I am sure that it is not useless.
Greetings Thomas Mertes
--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
- Raw text -