Debug mode macros

44 views
Skip to first unread message

gabriel....@intel.com

unread,
Apr 23, 2015, 9:16:44 AM4/23/15
to nod...@googlegroups.com
Hi!

When I run npm install on my package which contains a native addon, it works. However, when I run npm install --debug, it fails, because one of the files uses DEBUG as an enum member, and so that effectively gets edited out by the preprocessor, breaking the syntax of the enum. I don't control the code that contains the offending enum member, so I was wondering if there is a way to tell node-gyp via binding.gyp to not add -DDEBUG to the command line when building in debug mode. It also adds -D_DEBUG, so that should still be sufficient.

Is it possible?

TIA for your help,



Gabriel

Ryan Schmidt

unread,
Apr 23, 2015, 2:57:51 PM4/23/15
to nod...@googlegroups.com

On Apr 23, 2015, at 5:26 AM, Gabriel Schulhof wrote:

> When I run npm install on my package which contains a native addon, it works. However, when I run npm install --debug, it fails, because one of the files uses DEBUG as an enum member, and so that effectively gets edited out by the preprocessor, breaking the syntax of the enum. I don't control the code that contains the offending enum member, so I was wondering if there is a way to tell node-gyp via binding.gyp to not add -DDEBUG to the command line when building in debug mode. It also adds -D_DEBUG, so that should still be sufficient.
>
> Is it possible?

I don't know. You should report the problem to whoever wrote the module that fails, so that they can fix it.



Jimb Esser

unread,
Apr 23, 2015, 10:01:01 PM4/23/15
to nod...@googlegroups.com
Honestly, a lot of modules fail, sometimes in subtle ways, in debug mode, (including very popular ones like "websocket" used by socket.io), as it is very common for the javascript-side to simply "require('../build/Release/foo');", which will not be the right path on a debug build, or might be a path to something stale from a previous build, etc.  When I was forced to use a "debug" version of Node at some point (which makes npm implicitly install in --debug mode by default), I eventually had to alias npm to always pass --debug=false to have anything with native code not break/misbehave, so I am now very wary of building anyone else's module in debug mode.

A much simpler question might be, can you just build your one module in debug, and leave everything else alone?

gabriel....@intel.com

unread,
Apr 23, 2015, 10:01:17 PM4/23/15
to nod...@googlegroups.com
Hey!
 I'm sorry! I wasn't clear in my original post. I'm writing the module, but I'm grabbing C code from another project via bower, and I don't know if there's anything I can put in binding.gyp or config.gypi or someplace that will result in removal of -DDEBUG from the compiler's command line.

gabriel....@intel.com

unread,
Apr 24, 2015, 1:22:49 PM4/24/15
to nod...@googlegroups.com
The solution:

```
"target_defaults": {
"configurations": {
"Debug": {
"defines!": [ "DEBUG" ]
}
},
},
```

Note the '!' in "defines!" - IOW, turn off debug.

gabriel....@intel.com

unread,
Apr 24, 2015, 1:22:57 PM4/24/15
to nod...@googlegroups.com
Hey!

So, I'm making some progress. Adding:
```
"target_defaults": {
"configurations": {
"Debug": {
"defines": [ "SPECIAL_DEFINE_FLAG" ]
}
},
},
```
to the top level of binding.gyp will cause node-gyp to add -DSPECIAL_DEFINE_FLAG to the compiler command line when building in debug mode. Great! I still need to know how to *remove* a flag that is being added by node-gyp itself.


The quest continues!



Gabriel

gabriel....@intel.com

unread,
Apr 24, 2015, 1:23:04 PM4/24/15
to nod...@googlegroups.com
Hey!

@Jimb Esser
The answer to the simple question you pose would only be useful if I were to
1. package the code which is sensitive to the -DDEBUG flag in a separate module (call it c-code) with its own package.json and everything, built in release mode, and
2. place the C++ bindings in a second module (call it cpp-code) which depends on c-code and is being built in debug mode.

This kind of setup feels unusual to me, because c-code would have absolutely no JS bindings, so the main.js or index.js or whatever I specify as the entry point of the package would do absolutely nothing. Nevertheless, if this is the structure things need to have for me to be able to test the native side of my C++ bindings, then so be it, and please, someone, let us know if it's possible to build a package in debug mode without building its entire dependency tree in debug mode as well.

The current setup is such that the C code which is sensitive to -DDEBUG is in the same package as the C++ code which provides node bindings to the C code. My original motivation for looking into debug mode was that I wanted to add instrumentation to my C++ bindings which compile conditionally on the presence of -DDEBUG or -D_DEBUG so that I may write tests in JS which would test the native side of my package. However, it looks like I'll have to come up with my own testing workflow because there's absolutely no documentation anywhere about how to affect node's debug mode CFLAGS and/or DEFINES via binding.gyp and/or config.gypi, and it also sounds like debug mode is a recipe for instability.

So, if somebody can please point me to some documentation about how to prevent node-gyp from passing -DDEBUG to the compiler when building in debug mode, then I would greatly appreciate that, because I would like to draw my own conclusions about the usefulness of debug mode given that my package has only one native dependency (ffi). In the meantime, I'll try to come up with an alternative workflow for debugging and testing my native code.

Thanks for all your help so far!



Gabriel
Reply all
Reply to author
Forward
0 new messages