nbind icon indicating copy to clipboard operation
nbind copied to clipboard

Windows - overriding nbind RTTI setting

Open ben-kirk opened this issue 8 years ago • 10 comments

I made a comment on this closed issue about not being to override RTTI... https://github.com/nodejs/node-gyp/issues/26

I'm using nbind on Windows 64-bit (with Electron). I later realized it appears nbind has it's own gypi (nbind.gypi) that seems to replace (or override?) the common.gypi that TooTallNate refers to in the above link. I could not override the default "false" RTTI setting using the methods he posted, but I was able to get past my problem (but not in an ideal way) by modifying nbind.gypi to have "true" (instead of default "false") for RuntimeTypeInformation setting. Is there a way to override this setting without having to modify nbind's infrastructure code?

ben-kirk avatar Nov 03 '16 15:11 ben-kirk

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...

jjrv avatar Nov 03 '16 16:11 jjrv

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.

ben-kirk avatar Nov 03 '16 16:11 ben-kirk

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

jjrv avatar Nov 03 '16 16:11 jjrv

Unfortunately, that did not work either.

ben-kirk avatar Nov 03 '16 17:11 ben-kirk

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.

jjrv avatar Nov 03 '16 17:11 jjrv

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

ben-kirk avatar Nov 04 '16 18:11 ben-kirk

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.

jjrv avatar Nov 04 '16 20:11 jjrv

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.

ben-kirk avatar Nov 04 '16 21:11 ben-kirk

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.

jjrv avatar Nov 05 '16 06:11 jjrv

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' } } }

mmppeegg avatar Oct 29 '20 22:10 mmppeegg