Compilation strategy

eles eles at eles.com
Mon Dec 17 01:13:26 PST 2012


On Monday, 17 December 2012 at 07:09:46 UTC, Jonathan M Davis 
wrote:
> On Sunday, December 16, 2012 22:58:26 Walter Bright wrote:
>> On 12/16/2012 10:27 PM, Jonathan M Davis wrote:
>> > If the entire .d file is there in binary form, then I don't 
>> > see why it
>> > wouldn't work. .di files fail because they strip out the 
>> > implementation.
>> > If a binary format were used,
>> 
>> It's all about what is in the file, not whether it is text or 
>> binary.
>
> The concept of .di files and their ilk is fundamentally broken 
> precisely
> because they're trying to strip what's in the file. That's what 
> causes the
> problems.

WRT to all opinions above (ie: binary vs text, what to put etc.)

I had some reflection on that some time ago: how about bundling a 
"header" file (that would be the .di file) and a binary file (the 
compiled .d file, that is the .obj file) into a single .zip 
(albeit with another extension), that will be recognized and 
processed by the D compiler (let's name that file a .dobj).

Idea may seem a bit crazy, but consider the following:

-the standard .zip format could be used by a user of that 
object/library to learn the interface of the functions provided 
by the object (just like a C header file)
-if he's a power user, he can simply extract the .zip/.dobj, 
modify the included header (adding comments, for example), then 
archive that back and present the compiler a "fresh" 
.dobj/library file

The responsability of maintaining the .obj and the header in sync 
will be of the compiler or of the power user, if the latter edit 
it manually. More, IDEs could simply extract relevant header 
information from the .zip archive and use it for code completion, 
documentation and so all.

Basically, this would be like bundling a .h file with the 
corresponding .obj file (if we speak C++), all that under a 
transparent format. The code is hidden and obfuscated, just like 
in a standard library (think -lstdc++ vs <iostream>). The use of 
a single file greatly facilitate synchronization, while the use 
of the standard .zip format allow a plethora of tools to manually 
tune the file (if desired).

This can be extended also to entire .dlib (that is, archive of 
.dobjs), which can become self-documenting, that way. I kinda of 
dreamt about that since programming in C++ and always needed to 
have the headers and the libs with me. Why do not include the 
headers in the lib, in a transparent and manually 
readable/editable format?

A checksum could guarantee also that the header information and 
the binary information are in sync inside the .zip archive.

What do you think?


More information about the Digitalmars-d mailing list