Is DEBUG macro automatically defined?

I have found a nice C++ library that I would like to use in my Swift package. However, the author defined a variable named "DEBUG". During compilation, I got:

xxx/CLaTeXMath/box/box.h:32:15: error: expected member name or ';' after declaration specifiers
  static bool DEBUG;
  ~~~~~~~~~~~ ^
<command line>:3:15: note: expanded from here
#define DEBUG 1

Right now, the only workaround I can find is to define DEBUG as DEBUG in my Package.swift:

    name: "CLaTeXMath",
    dependencies: ["tinyxml2"],
    cxxSettings: [
        // It seems that the compiler defines "DEBUG" as 1 somewhere.
        // There is a static variable named "DEBUG" in "box/box.h".
        .define("DEBUG", to: "DEBUG"),

But then, I got flooded by the warning message:

In file included from <built-in>:425:
<command line>:3:9: warning: 'DEBUG' macro redefined [-Wmacro-redefined]
<command line>:2:9: note: previous definition is here
#define DEBUG 1
1 warning generated.

I have two questions:

  • Is the macro DEBUG automatically defined in Swift?
  • What's the best way to approach this issue? Can I turn off this macro, or suppress the macro-redefined warning? Or should I just modify the source code?

Yes, it is a standard compilation condition handled by the package manager. DEBUG is defined when compiled with --confguration debug (which is also the default), and is undefined when compiled with --configuration release.

If you are already using unsafeFlags anyway (which restricts the ways the package can be used), you might try adding -Wno-macro-redifined or some such to suppress the warning.

Otherwise, I am unaware of any way to bypass the standard behaviour. I think you will have to modify the source code unless someone smarter than me knows of a better workaround.

Note that cxxLanguageStandard is a separate argument of the Package initializer, so you shouldn’t need unsafeFlags for this.

Thanks! It is a nice feature to be builtin. Didn't know that.

Yeah, I was considering that but I couldn't find a way to disable it individually. I think at the end of the day it would be easier to update the upstream code for long-term maintainability.

Oh thanks, I missed that!

Terms of Service

Privacy Policy

Cookie Policy