dblaikie added a subscriber: rsmith.
dblaikie added a comment.

In D137059#3899339 <https://reviews.llvm.org/D137059#3899339>, @ben.boeckel 
wrote:

> There is another motivating factor for 1-phase: the build graph is far 
> simpler. With 2-phase, CMake will have to write out rules to perform:
>
> - source -> .bmi
> - .bmi -> .withbmi.o
> - source -> .o
>
> because we do not know if a BMI is needed or not. If it isn't we use the 
> latter. If it is, we use the former. Note that this also means we need 2 
> different `.o` filenames (as neither `make` nor `ninja` doesn't support 
> multiple rules making the same output). This also means that the collator 
> needs to generate a response file for the linker to direct which `.o` file to 
> use for each TU based on the contents.

I /think/ from @rsmith's comments in the discourse thread, we're more likely to 
skip/remove the ability to go from ".bmi" -> ".o" and possibly have 2 path 
options (this is all from @rsmith's comments on discourse) either ".cppm -> 
{.pcm, .o}" or ".cppm -> .o" + ".cppm -> .pcm" - this'd avoid the need to 
maintain full V slim pcm, there would never be a pcm that could produce a .o, 
.pcm would only be sufficient for users, not implementation.

But yeah, maybe we end up with all 3 options in the interim. Though I'd really 
like to keep the surface area as small as possible, while still allowing room 
for experimentation. Perhaps experimentation via -Xclang flags until data shows 
the options are worthwhile beyond those experiments.

Pulling in your (Ben) comment from D137058 <https://reviews.llvm.org/D137058>:

> Plus the other compilers offer controls over it; why does Clang have to be 
> different?

Which compilers/flags are you referring to? Arguments from compatibility with 
GCC are relatively easy to make (though I still have more hesitance for these 
flags since there's not wide-scale adoption, and I think there's still room to 
shape the world we want to see and limit the width of the interface/variations 
we end up having to support long term) & might side-step some of the 
discussions here.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137059/new/

https://reviews.llvm.org/D137059

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to