Hello Yigal,
On 22/10/2009 00:57, BCS wrote:
Hello Yigal,
As you said, what is needed is a better lib format. we already have
DDL NOW which already has most of what you described above. D can
also take advantage of the LLVM framework.
Does DDL or LLVM work to generate monolithic executable that use all
of D's features and do so for both Win32 and *nux?
Also, can I use notepad to view either of those file types?
from http://llvm.org/docs/LangRef.html
<quote>
The LLVM code representation is designed to be used in three different
forms: as an in-memory compiler IR, as an on-disk bitcode
representation (suitable for fast loading by a Just-In-Time compiler),
and as a human readable assembly language representation. This allows
LLVM to provide a powerful intermediate representation for efficient
compiler transformations and analysis, while providing a natural means
to debug and visualize the transformations. The three different forms
of LLVM are all equivalent.
</quote>
So, if your library has LLVM code representation, then it's easier to get
to but just as bad as reading a ASM dump from the compiler.
I'm being more than a bit sarcastic there, but keep in mind that 99% of the
info I'm interested in isn't in the assembly code (function names, argument
names, types, comments) and/or would be better viewed as the original source.
IIRC DDL wraps objects/libs with meta-data.
while it will be easy to get a text representation with llvm (the
equivalence that is mentioned above) why would you want to do it
anyway? Automatically extracted documentation to a human format (ddoc,
javadoc, etc) is much more useful and more flexible - you can get a
printed manual or an interactive and easy to navigate html, you can
also get all sorts of graphs and diagrams that would ease
understanding of the structure of code.
I'm cynical enough that I'd bet if D switches to a "smarter lib format" a
lot of people would manage to forget the documentation.
With the current system, the library must be shipped with, at a minimum,
a human readable list of prototypes.
the only valid IMO use case for header files is for linking libs - the
compiler can handle just find binary formats for that.
Truth be told I don't use .di files at all because I have yet to need to
use a codebase where I didn't have full source.
