No header files?

[Yigal Chripun]

On 22/10/2009 18:06, Denis Koroskin wrote:
> On Thu, 22 Oct 2009 19:59:04 +0400, Yigal Chripun <yigal100 at gmail.com>
> wrote:
>
>> Tomas Lindquist Olsen Wrote:
>>>
>>> This locks D to the LLVM backend, things like that is never a good idea.
>>>
>>
>> you could say the same thing about .net and Java -
>> Java locks you to .class files and .net locks you to assemblies.
>> there are many JVMs from different vendors for different platforms
>> which are interoperable because of this. IIRC Mono can work with MS
>> assemblies and also there's the interoperability between different
>> .net languages.
>>
>>> Also, LLVM bitcode files produced both by LDC and Clang/llvm-gcc are
>>> platform specific. Sure you can process them on any platform, but the
>>> source code they were compiled from was platform specific, and so is
>>> the resulting bitcode. Using LLVM bitcode as a replacement format for
>>> native OMF/COFF/ELF objects, does not give us platform neutrality.
>>>
>>
>> I don't know llvm that well but it seems that for clang/llvm-gcc the
>> reason for this is because of the source language (c/c++) which is
>> platform specific. Can you elaborate about this for LDC? where are the
>> problematic parts and what can be done to make the output
>> platform-neutral?
>>
>> I read that platform specific things like sizeof where hardcoded in
>> the resulting bit-code but now they replaced it with a sizeof
>> intrinsic so that the resulting bit-code would not depend on this. are
>> there any other problematic cases like this still remaining?
>>
>>> -Tomas
>>
>
> D source code:
>
> void main()
> {
> version (Windows) {
> writefln("Windows");
> } else {
> writefln("not Windows");
> }
> }
>
> Using the same LLVM IR for both platforms would be a mistake in the case
> above.
>
> The only solution would be to carry version and such stuff in IR, too,
> and resolve at later stages, but this is also problematic.

I think that postponing conditional compilation to a later stage is a 
reasonable solution.