Mail Archives: djgpp/2011/11/30/20:45:10
Hi,
On Nov 30, 5:01 pm, tm <thomas DOT mer DOT DOT DOT AT gmx DOT at> wrote:
> On Nov 30, 2:04 am, Rugxulo <rugx DOT DOT DOT AT gmail DOT com> wrote:
> > On Nov 29, 5:28 pm, tm <thomas DOT mer DOT DOT DOT AT gmx DOT at> wrote:
>
> > > I have no idea how to the fix the "Ambiguous redirect error". The
> > > purpose of the preprocessor macro C_COMPILER_VERSION is explained
> > > in a previous message.
>
> > GET_CC_VERSION_INFO = redir -o cc_vers.txt $(CC) --version
>
> 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).
> > > 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!) ;-)
> The new "mk_djgpp.mak" from the last post
> contains commands like
>
> echo "#define OBJECT_FILE_EXTENSION \".o\"" >> version.h
> echo "#define SEARCH_PATH_DELIMITER ';'" >> version.h
> echo "#define PATH_DELIMITER '\\\\'" >> version.h
>
> which should write
>
> #define OBJECT_FILE_EXTENSION ".o"
> #define SEARCH_PATH_DELIMITER ';'
> #define PATH_DELIMITER '\\'
>
> to the file "version.h". I would like to know, if my approach is
> working as expected. Please do a test.
See above (but I also intend to test, yet again).
> My newest attempt to solve
> the redirect problem is based on the "mk_djgpp.mak" file from
> the last post. It removes the line
>
> $(GET_CC_VERSION_INFO) cc_vers.txt
>
> and adds the line marked with +
>
> echo "#include \"direct.h\"" > chkccomp.h
> + echo "#define WRITE_CC_VERSION_INFO system(\"$(GET_CC_VERSION_INFO)
> cc_vers.txt\");" >> chkccomp.h
> echo "#define mkdir(path,mode) mkdir(path)" >> chkccomp.h
> echo "#define LIST_DIRECTORY_CONTENTS \"dir\"" >> chkccomp.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)
> 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.
> > > > And yet it still seems to do it when not using Bash. I don't know why.
> > > > Perhaps your Make is old 3.79.1?
>
> > > Yes, my DJGPP make has version 3.79.1
>
> > Some minor things changed between that one (old, stable) and (new,
> > modern) 3.81. That's why I mentioned it, I suspected it might be the
> > culprit. It might be easier to just have a .sh script (or even .BAT)
> > with simple compilation commands. Make is often overused and brittle,
> > kinda frustrating (IMO).
>
> 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.
> > > > > 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'm not sure *.cerrs is being created.
>
> > > You are right, no *.cerrs or *.lerrs are created.
>
> > > > You may still have blindly
> > > > assumed "2>" works everywhere.
>
> > > No, acually the preprocessor macro REDIRECT_C_ERRORS is
> > > used to redirect to *.cerrs. Since the macro is not
> > > defined in mk_djgpp.mak, no *.cerrs or *.lerrs is
> > > produced.
>
> > Well, since we have some weird errors somewhere, it might be a good
> > idea to temporarily enable logging of them. ;-)
>
> Without redirecting to *.cerrs the errors should be visible on the
> console.
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).
> > > > 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 ....
- Raw text -