[M3devel] replace build system??

[Rodney M. Bates]

On 06/01/2016 04:30 AM, Jay K wrote:
> We need to understand if and how well Modula-3 fits in the traditional and widespread C build infrastructure.

It doesn't, not very well.  A deep principle, if you can call it that, of C is that
each compilation has no knowledge of any other compilation.  Likewise, when linking
them together, it's all just binary stuff, addresses, constants, etc.  To get a
semblance of type-safe compilation, all coders have to correctly follow some variant
of a header file/#include idiom and create a matching makefile that correctly reflects
the actual interdependencies.  There is no checking that these are done correctly, and
from direct experience, I can say they are routinely done wrong.

All the modular languages have direct linguistic support for type-safe separate
compilation.  Implementing this correctly while using the C compilation model lies
somewhere between very kludgy and impossible.

>
> Does/can it retain its build speed if you invoke cm3 per .i3 and per .m3 file?

It couldn't possibly.  Typical front end compilation actual work is similar to
or less than executable program startup/shutdown overhead.  This effect
might be partially lost in the fact that m3cc is a separate executable and it
has to start up for every .[im]3 file.  But it would still about double the
number of program executions and startup overheads.

> Does/can it retain its incrementality?

I don't think this is possible all.  No matter what is in the makefile, Make
only understands dependencies among whole source files and must rebuild if
a depended-on file has been touched, even no changes to content.  Our current
build system works on declaration granularity.  (I presume this is what you
mean by incrementality."  I am not aware of any language-independent build
infrastructure that keeps track of dependencies on other that source file
granularity.

>
> Or do we really need to be more of the "driver" and do a lot of stuff at the lib/link level?
>

In a sense, we already have this.  Cm3 contains a sophisticated driver, a compiler
frontend, and language-specific link-time functions in one executable.  I see no
benefit and almost certainly losses, in putting these in different executables.

> - Jay
>
>
>
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: mika at async.caltech.edu; estellnb at elstel.org; m3devel at elegosoft.com; dabenavidesd at yahoo.es
>> Date: Tue, 31 May 2016 17:18:46 +0000
>> Subject: Re: [M3devel] replace build system??
>>
>> We should probably learn how to get the number of processors and optionally system load and make this more automatic.
>> Posix should standardize more of this. :(
>>
>> - Jay
>>
>>
>>
>>
>>
>>
>> ----------------------------------------
>>> To: estellnb at elstel.org; jay.krell at cornell.edu; m3devel at elegosoft.com
>>> To: dabenavidesd at yahoo.es
>>> Date: Tue, 31 May 2016 10:16:05 -0700
>>> From: mika at async.caltech.edu
>>> Subject: Re: [M3devel] replace build system??
>>>
>>> I mentioned this before a few times on this mailing list.... CM3 is already fairly
>>> parallel if you turn on the right options. Every back-end invocation can be done
>>> in parallel.
>>>
>>> Set M3_PARALLEL_BACK in the config to 10 or 20 and watch it go...
>>>
>>> "Daniel Alejandro Benavides D." writes:
>>> ...
>>>> A make-based build solution would have other advantages as well like=20
>>>> f.i. parallel build by make --jobs=3D4. That way CM3 could build up to=20
>>>> four times faster.
>>> ...
>>> _______________________________________________
>>> M3devel mailing list
>>> M3devel at elegosoft.com
>>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>>
>> _______________________________________________
>> M3devel mailing list
>> M3devel at elegosoft.com
>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>   		 	   		
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>

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