[PATCH] LLVM OpenMP CMake Overhaul

[C Bergström]

One of the previous comments in this thread was that there is an
assumption that libomp will be installed to /usr/lib or some system
directory. I absolutely don't believe that should be done. The
-fopenmp or equivalent flag should add the correct (private) includes
(C/C++/Fortran module) and -L/-rpath lib location. This is really
compiler internal and private. LLVM was the odd duck by relying on the
gcc OMP lib before. If llvm had Fortran support - that wouldn't likely
have ever happened from the start.


On Fri, Jun 26, 2015 at 4:04 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
> In http://reviews.llvm.org/D10656#195299, @jcownie wrote:
>
>> Chandler, the issue here is with providing a Fortran module that contains the OpenMP interfaces. Unfortunately, Fortran module files are a binary format file which has no standard specification. therefore to produce a module file for a specific compiler you have to compile the module with that compiler.
>>  The OpenMP standard wants it to be possible for Fortran users to "use omp_lib", that requires that an appropriate Fortran module file exists.
>>
>> So, the issue is not with the Fortran interface to C functions (the implementation of the Fortran module can use those interfaces if it wants to), but with the fact that Fortran compilers store modules in compiler dependent binary formats. Therefore you need the appropriate Fortran compiler to build the module file.
>>
>> If a distributor is building the runtime they need to either build the module file on the user's machine at install time (when they can see which Fortran compilers the user has to hand), to maintain a (small) Fortran compiler zoo to build appropriate modules, or explain to the user how to build the module when they install (almost the same as my first solution, but less automatic).
>
>
> Wow, thanks for the detailed explanation. I had no idea. =]
>
> So, it seems like this is only of minimal utility to even have in the CMake build, and sadly it brings a reasonable amount of complexity. Is there a reasonable way to separate it (and maybe to make it a script or something that users can easily run to, as you say, build the module for a particular install? Maybe that's the right balance between automatic and usable in different scenarios?
>
> I'm not sure at all, this is a nasty problem relative to the "normal" problems in our runtime libraries.
>
>
> REPOSITORY
>   rL LLVM
>
> http://reviews.llvm.org/D10656
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>