iains added a comment. In D118586#3336892 <https://reviews.llvm.org/D118586#3336892>, @ChuanqiXu wrote:
> In D118586#3336865 <https://reviews.llvm.org/D118586#3336865>, @iains wrote: > >> In D118586#3336612 <https://reviews.llvm.org/D118586#3336612>, @ChuanqiXu >> wrote: >> >>> (May off the patch) >> >> I am not sure what you mean here. > > I mean this comment is not related to the patch. So it doesn't mean to block > the patch landing. > >>> BTW, I know you also work on GCC frontend. I want to consultant what's your >>> opinion to uniform the command line options between Clang and GCC. Now it >>> looks totally different. I feel it would be a problem for clang. Since the >>> command line between clang and gcc are basically compatible so that user >>> who decide to use clang could turn back to use gcc whenever he want. But I >>> am worrying that it would be a harder decision for users if them are going >>> to use clang. Since the cost to use GCC again would be higher. >> >> We have the same objective: to keep user-facing options and functionality >> the same between clang and GCC (easier for both user and for build systems). >> The content of this patch does not alter that. BTW GCC also keeps the module >> name as "Primary:Parition" internally and user-facing output. //The module >> name in C++20 modules has no fixed mapping to the BMI/CMI filename on >> disk,.// > > I just tested the behavior of GCC. When I compile a partition interface unit > (let's name is `mod:part`), it would generate a file named `mod-part,gcm` > under the directory `gcm.cache`. So I feel what GCC does here is more > aggressive, it doesn't only choose the separator '-'. It would create an > cache directory by default. (I am not blaming it. I like the style too. > Otherwise, we need to sore CMI to a place by hand). What I want to say here > is that GCC would replace '-' to ':' when maps to the filesystem. I am OK to > not implement this in the series patch. But I hope we could get in consensus > that we should implement this. I think I am not explaining well enough ... Please execute "strings gcm.cache/mod-part,gcm" - you will see that the Module name is "mod:part" in the module file (GCC knows the module as mod:part internally, it is only the on-disk name that is changed). We //could// choose to use "mod-part.pcm" in our example test cases here, but it would not make any difference to the requirement - the mapping between module name and filename has to be determined by the mechanism that interfaces with the filesystem (we cannot impose that mapping on the module names internally to the compiler - since the mapping is unknown in the general case). So we would implement a basic interface (in the module loader, I suppose since that is available for jobs without a preprocessor) that would give pathNameForModuleName(ModuleName) ,... and probably moduleNameForPathName(PathName) ... those would interface to whatever means was used (e.g. ,module mapper, P1184 <https://reviews.llvm.org/P1184> etc). You could arrange for the default implementation to do the translation you see in GCC (mod:part <=> mod-part.pcm). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D118586/new/ https://reviews.llvm.org/D118586 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
