Windows - overriding nbind RTTI setting

[charto]

Windows - overriding nbind RTTI setting

[jjrv]

Try putting this in your own binding.gyp (inside the outermost curly braces):

    "msbuild_settings": {
        "ClCompile": {
            "RuntimeTypeInfo": "true" 
        }
    } 

I haven't tested it (Windows laptop is at home), but it might work...

[ben-kirk]

I tired it just inside outermost "{", but it did not override the rtti setting. I also tried inside ...'OS=="win"', { ... but it failed to override there too.

[jjrv]

Try putting the msbuild_settings at the end instead of the beginning of the file, maybe the includes are overriding it otherwise.

[ben-kirk]

Unfortunately, that did not work either.

[jjrv]

OK, now I did some testing and managed to patch the xcode_settings block so it should work similarly on Windows.

First of all, the lines I mentioned earlier can be at the beginning or end or even inside the targets block, it doesn't matter.

Second, the official nbind.gypi needs a patch. Line 63 should be:

"RuntimeTypeInfo%": "false"

I should probably add percent signs in various other places too. You can modify nbind code locally for now and I'll commit it to the official repo ASAP if it works.

[ben-kirk]

Another thing I just noticed in my nbind project... it seems all my relative paths included from binding.gyp have an extra ../
For example:

      'include_dirs': [
        'C:/Program Files/boost/boost_1_62_0',
        '../auto_discovery',
        '../Logger',
        '../utility',
        '../iconv'
      ], 

Inside my MSVS nbind Properties Pages / C/C++ / General /Additional Include Directories, these are listed as: ../../auto_discovery; ../../Logger; etc

[jjrv]

Do you mean it produces a Visual Studio solution with incorrect paths? Have you used node-gyp directly before and have you run into similar issues? If you're talking about paths manually entered into binding.gyp producing unexpected results in Visual Studio solutions, there might be something else besides nbind causing it.

I think the paths are supposed to be relative to binding.gyp and then it generates a solution under a new build subdirectory next to it, so paths with a ../ prefix in binding.gyp should have a ../../ prefix inside the build directory to refer to the same file or directory. Wonder if I understood your situation correctly.

[ben-kirk]

Yes, the VS sln has incorrect include/lib paths. If I use./<path> in binding.gyp, it puts it in the correct place for me../<path>so I can use that as a temporary workaround. Anyway, I have used node-gyp directly, but that project did not have relative paths so not sure if it was working ok... I can try looking into that.

[jjrv]

node-gyp modifies relative paths when producing files in different directories, so the target stays the same. Since the solution file is written in a new build subdirectory (I can't find an option to change this), an additional ../ prefix will always appear. Problems should only show up if you want to move the solution somewhere else.

I think node-gyp was mainly meant to compile, not produce a solution to use later. gyp itself is made for that and has a --generator-output option but node-gyp doesn't expose it because then node wouldn't find the binaries. See this node-gyp issue.

[mmppeegg]

This is piece of my binding.gyp. It doesn't work in Release build, but node-gyp default setting is Release build.
Sorry I don't know how to wrap my code.

"configurations": { 'Release': { 'VCLinkerTool': { 'AdditionalLibraryDirectories': [ 'C:/boost_1_67_0/stage/lib' ], }, 'VCCLCompilerTool': { 'ExceptionHandling': 1, 'RuntimeTypeInfo': 'true', 'AdditionalOptions': ['/GR'], } }, 'Debug': { 'defines': [ 'DEBUG', '_DEBUG' ], 'msvs_settings': { 'VCLinkerTool': { 'AdditionalLibraryDirectories': [ 'C:/boost_1_67_0/stage/lib' ], }, 'VCCLCompilerTool': { 'ExceptionHandling': 1, 'RuntimeTypeInfo': 'true' } } }