[PATCH] Support generating Jom-style depfiles.

Paul Robinson Paul_Robinson at playstation.sony.com
Fri Apr 24 17:11:46 PDT 2015


Re. origin of the -MV option, you are correct, it was a PS3 GCC option; the proprietary compiler always emitted NMake-style, it didn't have that option. My bad.

Re. UserManual.rst, it was not immediately obvious where to put this, so I invented a new section.  Let me know if you have a better idea.


================
Comment at: lib/Frontend/DependencyFile.cpp:153
@@ -152,2 +152,3 @@
   bool IncludeModuleFiles;
+  bool UseDoubleQuotes;
 private:
----------------
silvas wrote:
> Maybe a comment explaining why you would want double quotes? Alternatively, maybe instead of "bool" it could be `enum DepfileSyntax { Make, NMake }` or something like that.
Okay, an enum would be more self-documenting, and it's true there is more to it than just double-quotes.

================
Comment at: lib/Frontend/DependencyFile.cpp:298
@@ +297,3 @@
+                          bool UseDoubleQuotes) {
+  if (UseDoubleQuotes) {
+    // Add quotes only if needed.
----------------
silvas wrote:
> Is there a "spec" you can link to explaining the syntax? IIRC the microsoft docs for nmake have something explaining the quoting scheme.
There is online NMake documentation, but nothing explicitly saying when you do or don't need quotes.  I can cite the base NMake URL.

================
Comment at: lib/Frontend/DependencyFile.cpp:300
@@ +299,3 @@
+    // Add quotes only if needed.
+    if (Filename.find_first_of(" #$") != StringRef::npos)
+      OS << '\"' << Filename << '\"';
----------------
silvas wrote:
> I guess `#include <foo"bar.h>` is "don't do that"? I'm fine with that; I think the standard actually gives us a lot of freedom in what we can accept here; as long as we don't break use cases we care about it's all "implementation defined". We currently accept this though with no warning. If NMake doesn't have a way to quote this then maybe we should consider a "unadvisable include name" warning.
Double-quote is not a legal filespec character in Windows, so compilation would fail regardless.

That said, the purpose of quoting is to avoid the builder misinterpreting the string, and the set of characters that could cause trouble for NMake is more than what seems to be trouble for Make.  I should add curly braces and caret to this list, might as well add bang too, as they are all meaningful to NMake outside of recipes.

http://reviews.llvm.org/D9260

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the cfe-commits mailing list