ChuanqiXu added a comment. In D134267#3846153 <https://reviews.llvm.org/D134267#3846153>, @iains wrote:
> @ChuanqiXu BTW, I think we (unfortunately) have some overlap in work in > progress here; > > I have implemented a similar scheme to GCC's where C/BMIs can be produced "on > demand" when the FE encounters the module keywords. The idea was to make it > possible to have the same command lines on both compilers (basically to > remove the need for the user to identify that a c++ source is is modular - > with the sole exception of header units which the compiler cannot figure out > on its own). > > This scheme interfaces with the module-mapper approach (but how the mapping > is determined could just as easily be from command line flags, module map > files etc. etc. that is the beauty of that approach - the compiler has no > need to know about how the mapping is made - it can be a fixed in-process > scheme (like using the module cache path + some well-known mapping of names) > or a full-blown build system - e.g. attaching to build2 (I think Boris did > try out an earlier version of my implementation.) > > draft patches (need rebasing) here: D118896 > <https://reviews.llvm.org/D118896>, D118898 > <https://reviews.llvm.org/D118898>,D118895 > <https://reviews.llvm.org/D118895>, D118899 > <https://reviews.llvm.org/D118899> (these do not include the libCody stuff, > which would support the module mapper, but concentrate on the compiler side). > edit: D118895 <https://reviews.llvm.org/D118895> is probably no longer > relevant. > > Reworking/rebasing this scheme and posting the patches is next on my TODO > after (current work on) P1815 <https://reviews.llvm.org/P1815> part 2. > > Hopefully, there is some way to combine these pieces of work to give the user > greatest flexibility. @iains oh, I remembered just now that you said you'd like to take this in one of GitHub issues long ago. My bad. I forgot it when I started this. I think you can add me as subscriber such drafts next time to avoid similar things happen again. In fact, I had some drafts about modules and they conflicted with yours previously. So I'm sure I understand this : ( And for this concrete job (generate pcm and object file in one compilation job), I think my implementation looks better. It is shorter and reuses the current behavior (generate `.pcm` files in `/tmp` directories and we just redirect it). So I think it may be better to pursue this patch for this task. (The option design could be changed of course). --- (following off may not be related to this patch) And it is definitely valuable to have command line interfaces compatibility between clang and gcc. But for the libcody things, we must need a RFC in the discourse first. Also for the module mapper things, I'm not sure if we should pursue it. (I'm not against it. I'm just hesitating). For example, I am trying to implement the proposal P1689 <https://reviews.llvm.org/P1689> from kitware guys in https://github.com/ChuanqiXu9/llvm-project/tree/MyP1689/P1689Examples/HelloWorld. And it looks good that we can compile a hello world example now. So I'm not sure if the gcc's module mapper is necessary here. Maybe we need more discussing. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134267/new/ https://reviews.llvm.org/D134267 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
