Yigal Chripun wrote:
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.
I just don't see how having another file is any sort of burden. People
have been doing it for a very long time.
I was suggesting to convert *both* obj files and lib files to llvm
bit-code. such library files will still contain the metadata.
I understand, but it's a lot of code to write to eliminate a file - and
with other downsides like not being human readable.
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).
Right now, you can hook D up to any language that supports a C
interface. It's not necessary to convince them to use LLVM, too.
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..
Shared libraries are inherently not portable from system to system.
