[M3devel] replace build system??

[Rodney M. Bates]

On 06/03/2016 12:18 PM, Elmar Stellnberger wrote:
>
>>>
>>>    Or, really, more simply, just accept a bunch of .mc/ms file pairs
>>> and process them
>>>    separately as usual, but within one m3cg invocation.
>>>
>>
>> I like this idea, but we don't want to force serialization where we now
>> do parallel
>> runs of m3cg.
>>
>> OTOH, it has puzzled me why, when compiling m3cc or m3gdb, the C compile
>> commands
>> seem to scroll by slower than the unit compiles when running cm3,
>> despite the fact
>> that the latter include a main program invocation of m3cc.  Surely it's
>> not merely
>> smaller units?  And we are also running separately too.
>>
>
> Mika Nystroem, do you mean by 'setting M3_PARALLEL_BACK to 10 or 20' that the backend would generate code in parallel?
>   - This would not be right what I want because actually obtaining deterministic build results is of high value for security reasons. It can be necessary to verify whether a given compiler toolkit / build environment must have been infected at the stage of build time with hindsight.
>    I know deterministic builds are quite hard to realize even for some C/C++ applications; nonetheless I had never been thinking about Modula-3 or CM3 in specific. At least it was a well known problem with Python that builds were non-deterministic due to parallel code generation.
>    However that should not happen if just different source files are translated at the same time. Moreover that could also parallelize the activity of the front (and middle)-end.
> ___

I don't believe the builder bugs I was talking about have anything to do with parallel
compilation.  In fact, they happen with no parallelism.  Mika can weigh in, but I am
sure the parallelism is carefully synchronized so the resulting compiled code is entirely
deterministic, even when the cpu usage getting there is not.


____________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>

-- 
Rodney Bates
rodney.m.bates at acm.org