[RFC] New clangOptions library; Remove dependency on `clangDriver` from `clangFrontend` and `flangFrontend`

Clang Frontend
1

Problem

As part of implementing [RFC][Modules] Support simple C++20 modules use from the Clang driver without a build system, we need to perform a dependency scan from the Clang driver.

This was followed by [RFC][Driver] Link the Driver against clangDependencyScanning, which got approval. However, during review of [clang][modules-driver] Add dependency scan and dependency graph (#152770 ), it was pointed out that this introduces cyclic dependencies and would fail with dynamic linking.

Proposal

To solve this, we need to break clangFrontend’s dependency on clangDriver and propose the following changes:

  1. Extract option-related code from clangDriver into a new clangOptions library. Both clangDriver and clangFrontend can then depend on clangOptions independently.
    This would be addressed by #163659.

  2. Move other functionality from clangFrontend that depends on clangDriver into clangDriver itself, inverting the dependency relation.
    This is currently implemented in PR #165277 and also removes the clangDriver dependency from flangFrontend, as requested by Flang maintainers.

The direct dependency of clangDependencyScanning on clangDriver would be removed in a later step, as per this review comment.

@tarunprabhu @sscalpone @rnk @MaskRay @kiranchandramohan @jansvoboda11 @Endill @banach-space @cachemeifyoucan @Bigcheese @AaronBallman

Thanks for everyone’s time and input on this.

:white_check_mark: This RFC was accepted in this message.

5 Likes
2

Thank you for the RFC! I think this approach makes sense, but I’d love to hear from the driver and options code owners too.

3

This sounds good to me.

1 Like
4

Better separation of concerns is useful on a variety of levels. So I am in favor.

1 Like
5

Given the lack of stated concerns, this RFC is accepted. Thanks!

1 Like