<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Olaf, I don't entirely agree.<BR>
The logs should be fairly informative <EM>without </EM>intervention.<BR>
Just not too verbose. I'd would rather remove the lines that say "compiling" and show the cm3cg invocations.<BR>
But more than one line per source file is too much.<BR>
-commands doesn't really work. Lots of bogus extra commands are echoed (rm .tmp), and not all the commands that are run are echoed.<BR>
<BR>
I understand that stability for tests is also a goal, but information for the interactive user and for post mortem debugging via a log is also valuable, and these are contrary to stability-for-tests. Somehow contradictory goals need to be met.<BR>
<BR>
How about a compromise?<BR>
How about we always log more stuff to TARGET/cm3.log?<BR>
And then exactly what you want to stdout/stderr?<BR>
While, as I said, more than one line per file is overkill, as part of this compromise I'd be willing to include the cm3cg and as invocation.<BR>
<BR>
Have folks used build.exe in the Windows NT DDK?<BR>
It's model is close to what you get here.<BR>
It has three sets of information:<BR>
to the console/stdout <BR>
build.log, build.exe is a wrapper over make, and this includes all the make output -- all the command lines run <BR>
build.err, a small subset of console/stdout output<BR>
<BR>
My "design" here has been to avoid over-verbosity. Link and mt run on the order of once, or a small number of times, per directory, so showing the full command line (response files...) isn't so verbose -- vs. say something shown once per compiled file.<BR>
<BR>
There's another "problem" here that I have partly fixed.<BR>
Underlying errors are not shown on console/stdout/stderr.<BR>
They are often in like TARGET/m3core.lst.<BR>
<BR>
I changed stuff to refer to that file, after having hunted the errors down myself slowly the first time.<BR>
<BR>
We could change things to alway says "see TARGET/cm3.log" for more information, or somesuch.<BR>
<BR>
- Jay<BR><BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Tue, 6 May 2008 10:07:11 +0200<BR>> From: wagner@elegosoft.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] www.opencm3.net/m3tests<BR>> <BR>> Quoting Jay <jayk123@hotmail.com>:<BR>> <BR>> > The "problem" here, a really really small one, is just that the link <BR>> > and mt commands got echoed.<BR>> > Olaf made them not echoed. I then made them conditionally echoed.<BR>> > I made m3-sys\m3tests define M3TESTS so that NT386.common doesn't echo.<BR>> > It's not a big deal either way.<BR>> > Aha -- tests in other directories would have a problem, and I think <BR>> > there are some.<BR>> ><BR>> > I like more echoing usually, so the system explains what is going on,<BR>> > instead of the vaguer "linking foo" sort of message.<BR>> > Granted, nobody bothers watching gcc run assembler commands, so I <BR>> > guess it is just quite gray.<BR>> <BR>> Jay, cm3 needs to behave the same on all platforms. By default<BR>> commands should _not_ be echoed to stdout or stderr; that's what the<BR>> -commands switch is for: this gives you exactly the commands the<BR>> compiler issues to invoke other tools.<BR>> <BR>> For more verbose output, you may also depend on the -verbose or the<BR>> -debug switches.<BR>> <BR>> Please adapt the configuration files that bey default all echoing<BR>> of commands is off.<BR>> <BR>> Olaf<BR>> <BR>> > I don't know how to run the Tinderbox either yet, sorry.<BR>> > I tried.<BR>> ><BR>> > For adding tests, well, there is m3-sys\m3tests.<BR>> > That is where a lot of the tests are, but not all.<BR>> > I am not sure where tests belong. I added a small number there.<BR>> > They are named with just a letter and a number.<BR>> > The letters have some meaning, explained in the m3makefile.<BR>> > "p" is programs that are run and their stdout/stderr compared <BR>> > against expected<BR>> > "e" is programs build and the errors from the compiler checked to be <BR>> > reasonable.<BR>> > I don't think in general they are expected to successfully compile <BR>> > or run, though the case of "warnings" may be unclear.<BR>> > "c" is programs built so a human can look at the generated code.<BR>> > There is another case I think for human checking.<BR>> > The numbers are just 001, 002, 003, etc.<BR>> > Each hundred tests are in a separate directory, like p0\p001, <BR>> > p0\p002, p1\p100, p1\101, etc.<BR>> ><BR>> > Something like this.<BR>> > Wherever I have details wrong, just look in m3-sys\m3tests. It's <BR>> > pretty simple, obvious, and well commented.<BR>> ><BR>> > The output is a little clearer if you have a working diff.exe on the path.<BR>> > Then what you do is search for "@@" in the output.<BR>> ><BR>> > - Jay<BR>> ><BR>> ><BR>> > Date: Tue, 6 May 2008 03:46:27 +0200From: dabenavidesd@yahoo.esTo: <BR>> > m3devel@elegosoft.comSubject: [M3devel] www.opencm3.net/m3testsDear <BR>> > developers:Does the recent tests on NT386 seem broken because a <BR>> > recent change on the m3-sys tree, or is the HTML bad generated, I <BR>> > mean can you check the last tests Sunday, May 4th (p001 to p042) has <BR>> > a red background <BR>> > http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html</pre></td></tr> <tr class="bgred tl"><td> p002 </td><td class="small" width="45%"> Text</td><td class="small"><pre>Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILDFC: no differences encounteredComparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGMFC: no differences encounteredComparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences encounteredand almost the same pattern in the above tests.I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.Also what is the best natural way to put a new tests, and the standard name it should <BR>> > have?Thanks<BR>> ><BR>> ><BR>> > Enviado desde Correo Yahoo!La bandeja de entrada más inteligente.<BR>> <BR>> <BR>> <BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR><BR></body>
</html>