Compilation strategy

[Walter Bright]

On 12/17/2012 1:53 PM, Rob T wrote:
> I mentioned in a previous post that we should perhaps focus on making the .di
> concept more efficient rather than focus on obfuscation.

We're not going to do obfuscation, because as I explained such cannot work, and 
we shouldn't do a disservice to users by pretending it does. There are many ways 
that *do* work, such as PIMPL, which work today and should be used by any 
organization wishing to obfuscate their implementation.


> Shorter file sizes is a potential use case, and you could even allow a
> distributor of byte code to optionally supply in compressed form that is
> automatically uncompressed when compiling, although as a trade off that would
> add on a small compilation performance hit.

I suspect most file transport protocols already compress the data, so 
compressing it ourselves probably accomplishes nothing. There are also 
compressed filesystems, so storing files in a compressed manner likely 
accomplishes little.

I have toyed with the idea many times, however, of having dmd support zip files. 
Zip files can contain an arbitrary file hierarchy, with individual files in 
compressed, encrypted, or plaintext at the selection of the zip builder. An 
entire project, or library, or collection of source modules can be distributed 
as a zip file, and could be compiled with nothing more than:

    dmd foo.zip

or:

    dmd myfile ThirdPartyLib.zip

and have it work. The advantage here is simply that everything can be contained 
in one simple file.

The concept is simple. The files in the zip file simply replace the zip file in 
the command line. So, if foo.zip contains a.d, b/c.d, and d.obj, then:

    dmd xx foo.zip

is equivalent to:

    unzip foo
    dmd xx a.d b/c.d d.obj

P.S. I've also wanted to use .zip files as the .lib file format (!), as the 
various .lib formats have nothing over .zip files.