iains added a comment. In D134267#3846218 <https://reviews.llvm.org/D134267#3846218>, @ChuanqiXu wrote:
> 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). I need to review this patch some more - but at first looking it seems to be driver-only - so I am not sure how you are arranging for the PCM **and** the object to be created from a single invocation of the FE. The idea of my patch series is to match the behavior o GCC - where the FE can figure out (independently of any file suffix) that it needs to emit an BMI. > --- > > (following off may not be related to this patch) perhaps - but a small response here (we can take this to a different forum if needed) > 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. Well the idea had also been discussed among the 'modules group' but. sure we can this - however the module-mapper is not required to make this initial patch series useful on its own - it is about automatically producing the BMI without special command lines. > 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. There is almost certainly more than one solution to this and different solutions will fit different scenarios - Cmake and build2 are examples, but actually it's quite nice with a small project to be able to use an in-process resolver for names and not require any external build system. I realise a lot of discussion in SG15 is targeted at the larger scale problems, but we should also provide (as you suggest) for "hello world" - preferably without the user having to install a separate package to make it work. 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
