GSOC Linker project

foobar foo at bar.com
Fri May 4 13:14:03 PDT 2012


On Friday, 4 May 2012 at 19:13:21 UTC, Steven Schveighoffer wrote:
> On Fri, 04 May 2012 15:07:43 -0400, Andrej Mitrovic 
> <andrej.mitrovich at gmail.com> wrote:
>
>> On 5/4/12, Steven Schveighoffer <schveiguy at yahoo.com> wrote:
>>> Current tools:  read .di files and extract API
>>> new tools: read .dobj files and extract API.
>>>
>>> I'm not really seeing the difficulty here...
>>
>> I thought he meant libraries that are only distributed in 
>> binary form.
>> So no .di files anywhere. Maybe I misunderstood..
>
> No reason for .di files if the object file already serves as 
> the interface file.
>
> I think he meant that object (and library) binary files would 
> be augmented by API segments that provide what di files provide 
> now -- an interface-only version of the code.  It doesn't have 
> to be text, it can be binary (maybe even partially compiled).
>
> The really nice thing you get from this is, the compiler now 
> would use this object file instead of .d files for importing.  
> So not only do you eliminate errors from having two possibly 
> separately maintained files, but the compiler can build *extra* 
> details into the .dobj file.  For example, it could put in 
> metadata that would allow for full escape analysis.  Or tag 
> that a function is implied pure (without actually having to tag 
> the function with the pure attribute).
>
> -Steve

Exactly :)



More information about the Digitalmars-d mailing list