vladimir.plyashkun added a comment. Thanks @klimek for the response! Let me give an example. Suppose we want to check //main.cpp// by clang-tidy. As i said before, i cannot use //CompilationDatabase.json// (due to some technical reasons), but there is way to pass all options though command line and call external process of clang-tidy in this way: `clang-tidy -checks=* main.cpp -export-fixes=... -- -std=c++11 -Ipath/to/include -Ipath/to/include2 -DMACRO ....` All compiler related options appear in the command line after `--` symbol. But due to command line length restrictions (especially on Windows OS) it's better to use //@ResponseFile// mechanism. To achieve it, i've created //arguments.rsp// file with this content: `-checks=* main.cpp -export-fixes=... -- -std=c++11 -Ipath/to/include -Ipath/to/include2 -DMACRO ....` and tried to call clang-tidy in this way: `clang-tidy @arguments.rsp` But all compiler options are ignored by this call! If you check how //CommonOptionsParser.cpp// parses command line arguments, you will see, that first of all, it tries to load fixed compilation database (by finding `--` symbol in the command line). Only after that it calls //cl::ParseCommandLineOptions// which loads content of //arguments.rsp// file and parses all the rest arguments. So, my question was why not to expand response files before loading fixed compilation db from command line? Or i'm doing something wrong?
Repository: rL LLVM https://reviews.llvm.org/D34440 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
