On 22/10/2009 21:57, Walter Bright wrote:
Yigal Chripun wrote:
let's go over the list one more time: 1) i can't use obj files from
different OSes or even different compilers on the same OS - so
definitly *not* platform neutral
Yes, but the .di files *are* platform neutral.
2) you need to parse a header file
in addition to linking functions from the lib file, how is that
better than having one file without needing to do any parsing of
headers at all?
You still have to read that file and get it into the D front end's data
structures.
3) like Steve said, there is only one file so you
don't get syncing problems between the header and the object file.
Setting up a build tool to handle dependencies is trivial, and one
already has to do that for object files, but even that step isn't
necessary as D can simply use the original source file as its "header"
file. .di files aren't necessary at all.
that's a different use case. *If* full sources are available than I
could just compile everything myself.
What we're talking about is commercial companies that do not provide
full sources. In Java this is trivial - just provide jar(s), in .Net
it's trivial - just provide assemblies. in D you need to provide both a
library file *and* di header files.
the bit-code object file already contains all the required metadata
and doesn't depend on a separate header file.
Something has to convert metadata into the D front end's data structures.
4)LLVM is already
implemented and has all the required tools for its format. ldc for
example can take advantage of this easily.
.di files are already implemented and work across all D implementations!
BTW, a point not mentioned is that dmd can build library files directly,
without making object files. This would break if there had to be
metadata in those object files needed by the front end.
I was suggesting to convert *both* obj files and lib files to llvm
bit-code. such library files will still contain the metadata.
what I ultimately want is to have something similar in concept to .net
asseblies/java Jars but with native code (no VM involved). LLVM provides
the infrastructure to do exactly this: the compiler generates platform
neutral D-assemblies (in llvm bitcode) that can be used on any
architecture/OS/llvm-compiler. This would also allow us to use libraries
written in other languages when there's an appropriate llvm compiler for
them (Ruby, scheme, python, etc).
Another issue that's not mentioned here is shared libraries and D.
there's no one simple way to have D shared libraries, and especially on
windows (90% market share...) dlls are *not* a solution at all. there
are 3rd party tools like DDL but I'd like to see *one* solution that
works on all platforms and directly supported by D. major D libraries
need to be shared libs - the runtime, the stdlib, the GUI libs, etc..
