No header files?

[Yigal Chripun]

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..