Mail Archives: djgpp/2011/11/30/18:15:14
On Nov 30, 2:04 am, Rugxulo <rugx DOT DOT DOT AT gmail DOT com> wrote:
> Hi,
>
> 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?
> > 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.
> But yes, the problem is that *nix and DOS behave differently:
>
> echo hello "silly" world > blah.txt
>
> DOS: hello "silly" world
> Linux: hello silly world
An echo command in a makefile might work differently from an echo
command in a console window. It seems that on your computer echo
commands in a makefile work like Linux echo commands. I tried to
take that into account. 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. 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
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.
> > The only difference to the last version are the rules to produce
> > "version.h" with echo commands.
>
> > Please try this makefile (be careful the usenet system (google
> > groups) might add line breaks), and tell me what is still missing.
>
> Okay. You could also email me if that's easier. Though I think (?) I
> can handle it for now. ;-)
Thank you in advance, for your effort.
> > > 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.
> > > > 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.
> > > 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 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.
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 -