alexfh added a comment. In https://reviews.llvm.org/D23455#515527, @rnk wrote:
> In https://reviews.llvm.org/D23455#515486, @brad.king wrote: > > > > the feasibility of emitting 'arguments' instead of 'command' into the > > > JSON compilation database. > > > > > > CMake constructs the command lines internally using string replacement on > > templates. We never actually know the exact arguments. Therefore > > providing arguments instead of the whole command would require parsing to > > be done on the CMake side instead. This is theoretically possible because > > we do know the shell for which we are generating (Windows `cmd` versus MSYS > > `sh`). However, it may also require a bunch of logic we don't have yet but > > that LLVM does. > > > > Alternatively, the JSON could have an additional `command_shell="..."` > > field that indicates the shell for which the command line is encoded. > > > Bummer. Given that this is hard to do in CMake, then I think we should just > tokenize in Clang. Let's use llvm::sys::getProcessTriple() instead of > LLVM_ON_WIN32 and check if that is an MSVC environment as a proxy for the > shell type. Do I understand correctly that `llvm::sys::getProcessTriple()` returns basically a compile-time constant? If yes, it won't allow the same clang tool binary to be used with both command line formats. Should we instead allow runtime selection of the command line format? For example, by extending JSON compilation database with the aforementioned `command_shell="..."` option. https://reviews.llvm.org/D23455 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
