[M3devel] builder behavior upon error -- subsequent files not fully compiled

[Jay K]

fyi, I observe the following:
 

When compiling multiple files,
and one fails,
the failure inappropriately affects later files,
in that, one or more of:
 

 - all outputs are deleted 
 - or -keep isn't honored 
 - or the "build pipeline" is truncated, i.e.  
   we might check the validity of .m3/.i3 files 
   but we don't progress all the way to generate 
   assembly/object files  
 
It used to be worse, we just discussed, I had regressed
it years ago by accident, in that compilation stopped
and no further errors are reported. But now it can
largely succeed, but not have the intended outputs,
so you fix the one error, and then recompile everything.
 

There is just one boolean "compile_failed" that is
set by the first failure, and left set, and the code
doesn't know if it was from an earlier file or the current file.
 

It either needs to be a counter, and captured before certain
steps and checked for > after them, or there should be
two booleans, one that is set/cleared per file, one that is
set whenever the first becomes set and is never cleared,
or functions should return a boolean, for the current file,
and either also set the "global", or set the global
near the top of the call tree.
 

It isn't global, but it is nearly so.
Making this code multithreaded will be an unfortunately large task..
 

I'll probably fix this soon.
This is just a heads up.
I'm not addressing the single-threadedness, just the other.
It shouldn't be a big change.
 

This is related to:
 What I'm actually seeing with one of the LLVM passes
 is the first invocation of some tool crashes, so the
 rest truncate their build pipeline and claim m3front failed,
 which isn't true, either it didn't run or didn't fail.
 The failure is from the first file.
 
 
 
 - Jay

 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150912/9fed1299/attachment-0001.html>