[all-commits] [llvm/llvm-project] ddd274: [flang] Put ISO_Fortran_binding.h where it can be ...

[Pete Steinfeld via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: ddd2747b7ee90026854a2957ee756dbaf3109f85
      https://github.com/llvm/llvm-project/commit/ddd2747b7ee90026854a2957ee756dbaf3109f85
  Author: Pete Steinfeld <47540744+psteinfeld at users.noreply.github.com>
  Date:   2023-10-30 (Mon, 30 Oct 2023)

  Changed paths:
    M flang/CMakeLists.txt
    A flang/test/Driver/ctofortran.f90

  Log Message:
  -----------
  [flang] Put ISO_Fortran_binding.h where it can be easily used (#70129)

The update stems from the discussion in

https://discourse.llvm.org/t/adding-flang-specific-header-files-to-clang/72442

This is my third attempt at this. My second attempt was in pull request
#69121.

This is my second attempt at this. My first attempt was in pull request
#68756.

This pull request has three changes from the second one:
- I put the test into the Driver directory rather than Examples so that
it would get run without require the define LLVM_BUILD_EXAMPLES.
- When installing ISO_Fortran_binding.h, I changed the location where it
was installed from.
- I changed the test so that it would work when flang was built with
shared libraries.

Here's the information from my previous attempts:

I decided to put ISO_Fortran_binding.h in a place where it would be
accessible with the include: "#include<ISO_Fortran_binding.h>" rather
than "#include<fortran/ISO_Fortran_binding.h>" because this is what
gfortran implements.

Note that the file is also installed into ".../include/flang", so if a
user wanted to access the file from a compiler other than clang, it
would be available.

I added a test in ".../flang/test/Driver". To make the test work, I also
needed to put ISO_Fortran_binding.h into the build area.

Although the flang project depends on clang, clang may not always be
available in a flang build. For example, when building just the
"check-flang" target, the "clang" executable may not be available at the
time the new test gets run. To account for this, I made the test's
script check for the existence of the "clang" executable. If "clang" is
not available, it simply prints "PASS". If it is available, it fully
builds and executes the test. On success, this will also print "PASS"