[M3devel] the matter of logging vs. NT386 C compilation

[Jay]

The Visual C++ compiler outputs source file name as they are compiled:
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c nul.cnul.c
 
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c nul.cnul.c
 
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c nul.c nul.cnul.cnul.cGenerating Code...
I believe that suppressing this will suppress all other warning/error output.
See, they both go to stdout:
D:\dev2\cm3\m3-libs\m3core>echo error > foo.c
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c foo.cfoo.cfoo.c(2) : fatal error C1004: unexpected end-of-file found
 
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c foo.c >nul
 
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c foo.c 2>nulfoo.cfoo.c(2) : fatal error C1004: unexpected end-of-file found
 
I tried something annoyingly expensive likecl -nologo -c foo.c | findstr /v /b /e foo.c 
 
which would only include lines that don't begin and end foo.c, but in normaluse, there are no such lines, there is just the one line, and so findstr fails, and so the overall command fails, not good.
 
You could do this:
 (echo. && cl -nologo -c foo.c)  | findstr /v /b /e foo.c 
Which nets you just a blank line output, but this seems to be heading to deep end, and even that blank line shouldn't be there.
Suggestions?
Maybe a change in cm3? Moving compile_c into it?My idea of moving Quake code into cm3 would be that cm3 has a definition of compile_c,but that if the user supplies compile_c, use that instead.
Doing that to solve just this is overkill, but it's not a bad idea anyway.
Smaller ideas could be considered, including:
1) Have all the compile_c implementations echo the source file, so they'd all have the same outputWhile is this is noisy in the user experience, there isn't much C.It does pollute all the platforms to cover up a small NT-specific problem.
2) What I suggested before, allow but to not encourage test cases to have per-platform results.This particular problem only affects test cases with C code, which is rare.There is one.
This would be very easy and solve the problem well.
It shouldn't be encouraged though, as it makes it more difficult to change the expected output of a test.
3) Currently if M3TESTS is defined, NT386.common redirects all C compiler output to nul.Good enough?
Related, in usage of GNU libtool, files are often compiled twice, once PIC, once not.The way it works, one invocation is directed to /dev/null, one is not.This would kinda sorta seem to set a precedent for redirecting C compiler output to /dev/null,except that they do run it both ways. It's not that errors are lost, just that they aren't doubled.
Also related, again, I suggest a log file.A detail hilighted here is that in fact ALL command would go to the log, and NONE would likelygo to stdout/stderr. Stdout/stderr would be strictly the domain of cm3.Perhaps cm3 could "sniff" for errors and pass them along, perhaps.
 
 
You know, really, the log file approach is already what is used for linking.
Why just linking? Why not everything run in the directory?
Ah, it looks like that isn't for all platforms though, just NT386.
 
I am half just making trouble here.
I think the logging should be more verbose, but even making it quiet is surprisingly difficult.
I guess the linking example shows the way though, I should just redirect C compiler output always to a file.
Maybe the same file as linking uses, maybe not.
The user experience in the face of error is, initially, badly degraded.
However there are ways to mitigate.
First, as with linking, upon error, we can tell the user about the file.
Second, upon error, we could just echo the file's contents to stdout.
It's just that for success, saying less is better.
 
I'll do that -- redirect to a file.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080508/2d901faa/attachment-0001.html>