output minimal .di files?

H. S. Teoh hsteoh at quickfur.ath.cx
Mon Jan 16 12:51:15 PST 2012


On Mon, Jan 16, 2012 at 12:32:01PM -0800, Adam Wilson wrote:
> On Mon, 16 Jan 2012 12:08:53 -0800, H. S. Teoh
> <hsteoh at quickfur.ath.cx> wrote:
[...]
> >One way to implement this is to store template/inline function bodies
> >inside the precompiled object files as extra info that the compiler
> >loads in order to be able to expand templates/inline functions,
> >compute the size of structs/classes (because private members are not
> >listed in the API file), and so on. How this is feasible to
> >implement, I can't say; some platforms may not allow arbitrary data
> >inside object files, so the compiler may not be able to store the
> >requisite information in them.
[...]
> Not a bad idea, it's similar in function to .NET's Metadata.
> unfortunately to be useful, other linkers would have to be taught how
> to read that data...
[...]

That depends on how you do it.

If we assume, for argument's sake, that we are allowed to store
arbitrary data inside an object file (say inside a debug section or
something), then the compiler could for example store things like parsed
function bodies, partial syntax trees, etc., that allows it to treat
templates and inline functions as though they actually were embedded in
the interface file. When asked to compile a source file that imports the
library, the compiler would read the object file, extract this info and
use it to do whatever it needs to do (expand templates, inline
functions, emit non-inlined function bodies, etc.).

The generated object file can then be linked by the system's usual
linker, assuming that the extra info in the library's object file is
marked such that the linker simply ignores it. The linker doesn't have
to know anything about it because the compiler has already done whatever
needs to be done with it when it compiled the source file that imported
the library.

In fact, if a particular platform doesn't support such extra data inside
object files, the compiler can simply save the data in its own internal
format in another file, and the library writer just ships this file
along with the human-readable API file and any precompiled library
object files. As long as the customer's compiler knows to look for this
file when compiling source that imports the library, it will have enough
info to do what it needs to do.


T

-- 
Everybody talks about it, but nobody does anything about it!  -- Mark Twain


More information about the Digitalmars-d-learn mailing list