Duplication of Compilation Logic on the mx and Java side

[mrigger]

Currently, the logic for compiling a file written in C, C++, or Fortran to LLVM IR or machine code is once on the Java side and once on the mx side. In Java, the test framework uses classes like GCC and opt. In mx, there are equivalent functions like compileWithGCC and opt.

It would be nice to remove this duplication of logic to easy maintenance when, e.g., adopting new versions of LLVM or GCC. It would probably be best to remove the Java part, since mx already takes care of downloading the dependencies. The Java part could then have a mx class from which the test framework can compile source files.

[chrisseaton]

Hmm I disagree. I think the logic for compiling language source files to LLVM IR should move completely into Java, including logic for finding or downloading compilers for you. Putting it into mx makes sense for development of Sulong, and for libraries shipped with R, but how will that work when we want to ship Sulong and compile source on the end user's machines like with Ruby C extensions?

[lukasstadler]

in R we also don't have mx at package installation time, we need to be able to do this from a makefile.

[mrigger]

Then I guess it would make more sense to remove the compilation logic from the mx side and move it to the Java side. For R, we can use whole-program-llvm or a similar tool.

[grimmerm]

#601