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