Compilation strategy

[Dmitry Olshansky]

12/18/2012 2:23 AM, Walter Bright пишет:
> On 12/17/2012 2:08 PM, Dmitry Olshansky wrote:
>> I really loved the way Turbo Pascal units were made. I wish D go the same
>> route.  Object files would then be looked at as minimal and stupid
>> variation of
>> module where symbols are identified by mangling (not plain meta data
>> as (would
>> be) in module) and no source for templates is emitted.
>> +1
>
> I'll bite. How is this superior to D's system? I have never used TP.
>

One superiority is having a compiled module with public interface (a-la 
.di but in some binary format) in one file. Along with public interface 
it retains dependency information. Basically things that describe one 
entity should not be separated.

I can say that advantage of "grab this single file and you are good to 
go" should not be underestimated.

Thusly there is no mess with header files out of date and/or object 
files that fail to link because of that. Now back then there were no 
templates nor CTFE. So module structure was simple. There were no 
packages (they landed in Delphi).

I'd expect D to have a format built around modules and packages of 
these. Then pre-compiled libraries are commonly distributed as a package.

The upside of having our special format is being able to tailor it for 
our needs e.g. store type info & meta-data plainly (not 
mangle-demangle), having separately compiled (and checked) pure 
functions, better cross symbol dependency etc.

To link with C we could still compile all of D modules into a huge 
object file (split into a monstrous amount of sections).

>
>> *Semantic info on interdependency of symbols in a source file is
>> destroyed right
>> before the linker and thus each .obj file is included as a whole or
>> not at all.
>> Thus all C run-times I've seen _sidestep_ this by writing each
>> function in its
>> own file(!). Even this alone should have been a clear indication.
>
> This is done using COMDATs in C++ and D today.

Well, that's terse. Either way it looks like a workaround for templates 
that during separate compilation dump identical code in obj-s to 
auto-merge these.

More then that - the end result is the same: to avoid carrying junk into 
an app you (or compiler) still have to put each function in its own section.

Doing separate compilation I always (unless doing LTO or template heavy 
code) see either whole or nothing (D included). Most likely the compiler 
will do it for you only with a special switch.


This begs another question - why not eliminate junk by default?

P.S.
Looking at M$: http://msdn.microsoft.com/en-us/library/xsa71f43.aspx
it needs 2 switches - 1 for linker 1 for compiler. Hilarious.


-- 
Dmitry Olshansky