Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows - overriding nbind RTTI setting #32

Open
ben-kirk opened this issue Nov 3, 2016 · 10 comments
Open

Windows - overriding nbind RTTI setting #32

ben-kirk opened this issue Nov 3, 2016 · 10 comments

Comments

@ben-kirk
Copy link

ben-kirk commented Nov 3, 2016

I made a comment on this closed issue about not being to override RTTI... nodejs/node-gyp#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?

@jjrv
Copy link
Member

jjrv commented Nov 3, 2016

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
Copy link
Author

ben-kirk commented Nov 3, 2016

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
Copy link
Member

jjrv commented Nov 3, 2016

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

@ben-kirk
Copy link
Author

ben-kirk commented Nov 3, 2016

Unfortunately, that did not work either.

@jjrv
Copy link
Member

jjrv commented Nov 3, 2016

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
Copy link
Author

ben-kirk commented Nov 4, 2016

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
Copy link
Member

jjrv commented Nov 4, 2016

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
Copy link
Author

ben-kirk commented Nov 4, 2016

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
Copy link
Member

jjrv commented Nov 5, 2016

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
Copy link

mmppeegg commented Oct 29, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants