GSOC Linker project
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).
More information about the Digitalmars-d