Specify LDC to compile specific files

[Michelle Long]

On Monday, 4 March 2019 at 16:59:10 UTC, Jacob Carlborg wrote:
> On 2019-03-03 17:44, Michelle Long wrote:
>
>> But one can only select one compiler using the build 
>> configuration. So in Visual D one has to use one compiler per 
>> project(one can switch at a click but that is it).
>> 
>> So version is useless to be able to do both.
>> 
>> Visual D could have a combo but it would then require 
>> versioning all the files.
>
> Aha, you mean like that.
>
>> If they are not ABI it might be a real problem getting it to 
>> work ;/
>
> The ABIs of DMD and LDC don't exactly the same. You should not 
> expect linking object files compiled with both compilers to 
> work.
>
>>> If you're using Dub you can do something like:
>>>
>>> "sourceFiles-ldc": ["some_file.d"]
>> 
>> 
>> And doing so will use dmd for all the others, compile 
>> some_file.d using ldc and then work all the details out?
>
> No, it will compile "some_file.d" if the compiler being used is 
> LDC, otherwise it will not be compiled.
>
>> This is essentially what I'm asking for in Visual D so to 
>> speak. To mark a file to use LDC and it will effectively do 
>> what dub is doing(if it is doing it as I stated).
>
> I misunderstood your question.

It's quite simple:

LDC takes about 10x longer to compile a project. But not all of a 
project needs LDC's optimization. Hence if one could easily split 
up parts and optimize those parts that need it then it would be 
better.

Ideally it might go like this:

pragma(compiler, LDC)
auto foo()


and the compiler would compile foo using ldc(somehow) and 
everything would work...

I realize that is a pipe dream but that would be a nice goal...

or have LDC itself be the main compiler but it would invoke dmd, 
which could be done by default, and then a pragma or file 
specifier would cause it to use the ldc compiler...

but if things are not ABI compatible I guess it won't work.

I don't know enough about the ABI specifics but if functions 
could be specified  such as the pragma and the machine could 
could directly be replaced then it shouldn't be a problem. If it 
would depend on parameters and globals then they could be checked 
for ABI compatibility and if it fails it won't compile, else it 
would.

The goal would be to avoid having to maintain multiple projects 
to do simple optimizations of functions and deal with all the 
those problems(essentially having to use libs/dlls(which still 
has the ABI issues anyways).

After all, really we are just talking about the specific machine 
code generated but they are functionally the same(or should be) 
so it shouldn't matter too much except for stuff passed in and 
out.

Know what the specific ABI issues are?