Compilation strategy

foobar foo at bar.com
Mon Dec 17 14:31:59 PST 2012


On Monday, 17 December 2012 at 22:12:01 UTC, Walter Bright wrote:
> 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.

Yes please.
This is successfully used in Java, their Jar files are actually 
zip files that can contain: source code, binary files, resources, 
documentation, package meta-data, etc. This can store multiple 
binaries inside to support multi-arch (as in OSX).
.NET assemblies accomplish similar goals (although I don't know 
if they are zip archives internally as well). D can support both 
"legacy" C/C++ compatible formats (lib/obj/headers) and this new 
dlib format.


More information about the Digitalmars-d mailing list