Compilation strategy

[Paulo Pinto]

On Tuesday, 18 December 2012 at 11:43:18 UTC, foobar wrote:
> On Monday, 17 December 2012 at 22:24:00 UTC, Walter Bright 
> wrote:
>> 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.
>>
>>
>>> *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.
>
> Honest question - If D already has all the semantic info in 
> COMDAT sections, why do we still require additional auxiliary 
> files? Surely, a single binary library (lib/so) should be 
> enough to encapsulate a library without the need to re-parse 
> the source files or additional header files?
>
> You yourself seem to agree that a single zip file is superior 
> to what we currently have and as an aside the entire Java 
> community agrees with use - Java Jar/War/etc formats are all 
> renamed zip archives.
>
> Regarding the obfuscation and portability issues - the zip file 
> can contain whatever we want. This means it should be possible 
> to tailor the contents to support different use-cases:
>  * provide fat-libraries as in OSX - internally store multiple 
> binaries for different architectures, those binary objects are 
> very hard to decompile back to source code thus answering the 
> obfuscation need.
>  * provide a byte-code solution to support the portability 
> case. e.g Java byte-code or Google's pNaCL solution that relies 
> on LLVM bit-code.
>
> Also, there are different work-flows that can be implemented - 
> Java uses JIT to gain efficiency vs. .NET that supports 
> install-time AOT compilation. It basically stores the native 
> executable in a special cache.

In Windows 8 RT, .NET binaries are actually compiled to native 
code when uploaded to the Windows App Store.