iains wrote: Let us try to determine fundamental constraints.
To produce a BMI (David's ImplementationBMI) that can generate the object file, it must contain all the AST. this is equivalent to hypothetical ` clang++ -x c++-module foo.cpp --prepcompile -fmodule-file=X=X-implementation.pcm` We can now take that pcm and generate both and object and an InterfaceBMI - by applying filters to the content and writing out a new BMI with the reduced content. (hypothetical command lines) ` clang++ X-implementation.pcm -fmodule-interfacee .... X.pcm` ` clang++ X-implementation.pcm -c -o foo.o` >From my perspective that seems to be requiring now three process launches to >generate two artefacts, plus we have to save the Implementation.pcm and >probably distribute it to different build nodes. The proposition of the patches here is (in the most common general case) to remove the step of generating the ImplementationBMI and to pipeline the filtering to the AST consumer that generates the Interface BMI. Whether we re-use wrapper code or make some new code is an implementation detail. It does not actually prevent you from taking the two-phase approach ( currently , `--precompile` will be unchanged in action). We might also have a version where the implementation PCM could be consumed to generate both object and Interface PCM from a single invocation - but that is still two processes + resources and saving the intermediate Impl. PCM I am generally concerned that we seem to be coming up with designs that require more and more process launches and corresponding memory footprint etc. https://github.com/llvm/llvm-project/pull/71773 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
