Skip to content

[Fortran] Use INTERFACE targets for options and dependencies - #193469

Merged
Meinersbur merged 9 commits into
llvm:mainfrom
Meinersbur:fortran_INTERFACE-depends
Jul 7, 2026
Merged

[Fortran] Use INTERFACE targets for options and dependencies#193469
Meinersbur merged 9 commits into
llvm:mainfrom
Meinersbur:fortran_INTERFACE-depends

Conversation

@Meinersbur

Copy link
Copy Markdown
Member

Use CMake INTERFACE libraries to express dependencies and common build options.

Using INTERFACE libraries was proposed here:
#171610 (comment)

Since such libraries can also propagate build options use this instead of target_compile_options. Unfortunately this does not mean we can get rid of flang_module_target because it also needs to set the module output directory.

@Meinersbur
Meinersbur requested a review from a team as a code owner April 22, 2026 11:15
@llvmbot llvmbot added the cmake Build system in general and CMake in particular label Apr 22, 2026
@Meinersbur
Meinersbur requested a review from petrhosek April 22, 2026 11:16
@Meinersbur

Copy link
Copy Markdown
Member Author

@petrhosek ping

@Meinersbur
Meinersbur requested a review from tarunprabhu May 21, 2026 11:57

@tarunprabhu tarunprabhu left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have used interface modules, but I can't say that I am very comfortable with them. But this looks reasonable to me.

Just a couple of minor nits.

Comment thread runtimes/cmake/config-Fortran.cmake Outdated
Comment thread runtimes/cmake/config-Fortran.cmake Outdated
if (CMAKE_Fortran_COMPILER_ID MATCHES "LLVM")
target_compile_options(fortran-compile-options INTERFACE
# Flang bug workaround: Reformating of cooked token buffer causes
# identifier to be split between lines

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know if this bug is being tracked? Just curious.

@Meinersbur Meinersbur May 21, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I created #139297 once as a special case of "flang cannot process its own preprocessor output". The output without -fno-reformat looks so broken that it might just not be intended to work. Breaking lines within identifiers is just the first issue I encountered. Or maybe & is supposed to concatenate them back together in fixed form mode? I do not know. In any case, #139297 was the more pressing issue and creating another issue that I don't even know enough about could have diverted from what matters.

Co-authored-by: Tarun Prabhu <tarunprabhu@gmail.com>
@Meinersbur

Meinersbur commented Jul 6, 2026

Copy link
Copy Markdown
Member Author

@tarunprabhu Could you re-review this. There were significant changes since your last review.

  1. Removal of fortran-link-depends etc. After [flang-rt] Implement iso module in C++ in the runtime #197687 there are no libraries anymore that require linking from Flang-generated object files. Potentially need to be re-added if we start implementing parts of the runtime in Fortran, but it would be unused currently.

  2. Re-add a "barrier" that [flang-rt][CMake] Avoid 'use, intrinsic ::' #205634 removed. While not needed for flang-rt internally anymore, it seems that target_link_libraries(libomp-mod PRIVATE flang-rt-mod) does not cause a target-level dependency on flang-rt-mod, only file-level dependencies. For the file-level dependencies to have an effect, ninja/make would first need to scan the dependencies which does not happen (or possibly does not know in by which search path the .mod file is going to be resolved by) until the .mod file exists in the first place.

@tarunprabhu tarunprabhu left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks reasonable to me. Thanks.

@Meinersbur
Meinersbur merged commit c6cadf9 into llvm:main Jul 7, 2026
77 of 79 checks passed
aobolensk pushed a commit to aobolensk/llvm-project that referenced this pull request Jul 8, 2026
…3469)

Use CMake INTERFACE libraries to express dependencies and common build
options.

Using INTERFACE libraries was proposed here:
llvm#171610 (comment)

Since such libraries can also propagate build options use this instead
of `target_compile_options`. Unfortunately this does not mean we can get
rid of `flang_module_target` because it also needs to set the module
output directory.

---------

Co-authored-by: Tarun Prabhu <tarunprabhu@gmail.com>
gandhi56 pushed a commit that referenced this pull request Jul 9, 2026
Use CMake INTERFACE libraries to express dependencies and common build
options.

Using INTERFACE libraries was proposed here:
#171610 (comment)

Since such libraries can also propagate build options use this instead
of `target_compile_options`. Unfortunately this does not mean we can get
rid of `flang_module_target` because it also needs to set the module
output directory.

---------

Co-authored-by: Tarun Prabhu <tarunprabhu@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cmake Build system in general and CMake in particular flang-rt

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants