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

deps,win: set MSVS .obj folders in gyp for V8 #13959

Closed

Conversation

jaimecbernardo
Copy link
Contributor

When V8 was updated to 5.7 and 5.8, there were issues compiling on Windows because of what was later discovered to be a filename conflict. This PR should avoid the issue in case it reoccurs when updating V8, without the need to change the number of shards.

Building on Windows fails depending on the result from sharding the deps/v8/src/v8.gyp:v8_base target. If two source files with the same name are in the same shard, their output object file path would conflict with one another. One example of this conflict is v8_base's runtime/runtime.cc and the V8 inspector's protocol/Runtime.cpp that is generated at build time, for which the files runtime.obj and Runtime.obj would be created, but MSVS overwrites one of them with the other.

Dividing the .obj output path by the original source's extension prevents this overwrite.

Refs: #12784
Refs: #12184
Refs: #11752
Fixes: nodejs/v8#4

/cc @nodejs/v8

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • commit message follows commit guidelines
Affected core subsystem(s)

deps,V8,build,windows

Building on Windows fails depending on the result from sharding the
deps/v8/src/v8.gyp:v8_base target. If two source files with the same
name are in the same shard, their output object file path would
conflict with one another. One example of this conflict is v8_base's
runtime/runtime.cc and the V8 inspector's protocol/Runtime.cpp that
is generated at build time, for which the files runtime.obj and
Runtime.obj would be created, but msvs overwrites one of them with
the other.

Dividing the .obj output path by the original source's extension
prevents this overwrite.

Fixes: nodejs/v8#4
@nodejs-github-bot nodejs-github-bot added the v8 engine Issues and PRs related to the V8 dependency. label Jun 28, 2017
@bzoz
Copy link
Contributor

bzoz commented Jun 28, 2017

/cc @nodejs/v8

@joaocgreis
Copy link
Member

LGTM from the Windows build side, but this should also get a review from someone with experience maintaining V8. This seems to be a more robust solution than the one I presented in #12184.

Copy link
Contributor

@refack refack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM from a GYP point of view

@ofrobots
Copy link
Contributor

Can we make this change upstream first?

# .cpp files in the same shard.
'msvs_settings': {
'VCCLCompilerTool': {
'ObjectFile':'$(IntDir)/%(Extension)/',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One request: replace last / with \\ (GYP shenanigans 🤷‍♂️ )

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, even worse $(IntDir)%(Extension)\\

Copy link
Contributor Author

@jaimecbernardo jaimecbernardo Jun 28, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, you mean you want the line changed like this: 'ObjectFile':'$(IntDir)%(Extension)\\',?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Testing it locally and then I'll submit a commit.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the feedback. Changes committed: 4ccd87b

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks.

@refack
Copy link
Contributor

refack commented Jun 28, 2017

Can we make this change upstream first?

Worth a shot, but we need to get used to maintain the V8 .gyp files on our own...
RE: https://docs.google.com/document/d/1gvHuesiuvLzD6X6ONddxXRxhODlOJlxgfoTNZTlKLGA

@ofrobots
Copy link
Contributor

Worth a shot, but we need to get used to maintain the V8 .gyp files on our own...

Sure. But as long as the file exists upstream, the fix should be made there first. Otherwise you'll potentially lose it the next time the V8 version is updated. At the least it will require extra care to make sure the locally floating patches are preserved each time an update to V8 is made.

@jaimecbernardo
Copy link
Contributor Author

Can we make this change upstream first?

@ofrobots would renaming one of the conflicting runtime files instead be a viable solution upstream? Do you know if other projects have dependencies on the file names, which one is better to rename? Or I can simply submit this.

@jaimecbernardo
Copy link
Contributor Author

@refack updated, PTAL. Thanks for your feedback.

@ofrobots
Copy link
Contributor

I personally think that the patch, as-proposed is better than possibility of renaming inspector's Runtime.cpp file as it is more future proof. /cc @eugeneo

@refack
Copy link
Contributor

refack commented Jun 28, 2017

@jaimecbernardo you could move this directive to https://github.com/nodejs/node/blob/master/common.gypi#L112 I can't think of any harm in having this globaly... (Well testing locally now)

@jaimecbernardo
Copy link
Contributor Author

@refack tried that, but it also needs changes to the projects that directly reference .obj files, like cctest:

node/node.gyp

Lines 562 to 638 in ef28d85

'target_name': 'cctest',
'type': 'executable',
'dependencies': [
'<(node_core_target_name)',
'deps/gtest/gtest.gyp:gtest',
'node_js2c#host',
'node_dtrace_header',
'node_dtrace_ustack',
'node_dtrace_provider',
],
'variables': {
'OBJ_PATH': '<(OBJ_DIR)/node/src',
'OBJ_GEN_PATH': '<(OBJ_DIR)/node/gen',
'OBJ_TRACING_PATH': '<(OBJ_DIR)/node/src/tracing',
'OBJ_SUFFIX': 'o',
'OBJ_SEPARATOR': '/',
'conditions': [
['OS=="win"', {
'OBJ_SUFFIX': 'obj',
}],
['GENERATOR=="ninja"', {
'OBJ_PATH': '<(OBJ_DIR)/src',
'OBJ_GEN_PATH': '<(OBJ_DIR)/gen',
'OBJ_TRACING_PATH': '<(OBJ_DIR)/src/tracing',
'OBJ_SEPARATOR': '/node.',
}, {
'conditions': [
['OS=="win"', {
'OBJ_PATH': '<(OBJ_DIR)/node',
'OBJ_GEN_PATH': '<(OBJ_DIR)/node',
'OBJ_TRACING_PATH': '<(OBJ_DIR)/node',
}],
['OS=="aix"', {
'OBJ_PATH': '<(OBJ_DIR)/node_base/src',
'OBJ_GEN_PATH': '<(OBJ_DIR)/node_base/gen',
'OBJ_TRACING_PATH': '<(OBJ_DIR)/node_base/src/tracing',
}],
]}
]
],
},
'includes': [
'node.gypi'
],
'include_dirs': [
'src',
'tools/msvs/genfiles',
'deps/v8/include',
'deps/cares/include',
'deps/uv/include',
'<(SHARED_INTERMEDIATE_DIR)', # for node_natives.h
],
'libraries': [
'<(OBJ_GEN_PATH)<(OBJ_SEPARATOR)node_javascript.<(OBJ_SUFFIX)',
'<(OBJ_PATH)<(OBJ_SEPARATOR)node_debug_options.<(OBJ_SUFFIX)',
'<(OBJ_PATH)<(OBJ_SEPARATOR)async-wrap.<(OBJ_SUFFIX)',
'<(OBJ_PATH)<(OBJ_SEPARATOR)env.<(OBJ_SUFFIX)',
'<(OBJ_PATH)<(OBJ_SEPARATOR)node.<(OBJ_SUFFIX)',
'<(OBJ_PATH)<(OBJ_SEPARATOR)node_buffer.<(OBJ_SUFFIX)',
'<(OBJ_PATH)<(OBJ_SEPARATOR)node_i18n.<(OBJ_SUFFIX)',
'<(OBJ_PATH)<(OBJ_SEPARATOR)node_url.<(OBJ_SUFFIX)',
'<(OBJ_PATH)<(OBJ_SEPARATOR)util.<(OBJ_SUFFIX)',
'<(OBJ_PATH)<(OBJ_SEPARATOR)string_bytes.<(OBJ_SUFFIX)',
'<(OBJ_PATH)<(OBJ_SEPARATOR)string_search.<(OBJ_SUFFIX)',
'<(OBJ_PATH)<(OBJ_SEPARATOR)stream_base.<(OBJ_SUFFIX)',
'<(OBJ_PATH)<(OBJ_SEPARATOR)node_constants.<(OBJ_SUFFIX)',
'<(OBJ_PATH)<(OBJ_SEPARATOR)node_revert.<(OBJ_SUFFIX)',
'<(OBJ_TRACING_PATH)<(OBJ_SEPARATOR)agent.<(OBJ_SUFFIX)',
'<(OBJ_TRACING_PATH)<(OBJ_SEPARATOR)node_trace_buffer.<(OBJ_SUFFIX)',
'<(OBJ_TRACING_PATH)<(OBJ_SEPARATOR)node_trace_writer.<(OBJ_SUFFIX)',
'<(OBJ_TRACING_PATH)<(OBJ_SEPARATOR)trace_event.<(OBJ_SUFFIX)',
],

Those references can be updated to make it build, but another impact that change would have if applied globally is causing the C++ linter to show warnings due to trying to open the .cc folders created. This PR's changes applied to the v8_base target only bring the least impact overall.

@refack
Copy link
Contributor

refack commented Jun 28, 2017

This PR's changes applied to the v8_base target only bring the least impact overall.

I agree that's safest. Then we need to push this upstream. If you want I can do it I have the setup and did chromium contribution dance already...

@jaimecbernardo
Copy link
Contributor Author

@refack Thanks, but I want to use this opportunity to setup and learn the steps as well.

@jaimecbernardo
Copy link
Contributor Author

@refack @ofrobots Opened https://chromium-review.googlesource.com/c/556599/ to get this into V8. PTAL

kisg pushed a commit to paul99/v8mips that referenced this pull request Jun 30, 2017
Building on Windows with gyp fails depending on the result from
sharding the src/v8.gyp:v8_base target. If two source files with the
same name are in the same shard, their output object file path would
conflict with one another. One example of this conflict is v8_base's
runtime/runtime.cc and the V8 inspector's protocol/Runtime.cpp that
is generated at build time, for which the files runtime.obj and
Runtime.obj would be created, but MSVS overwrites one of them with
the other.

Dividing the .obj output path by the original source's extension
prevents this overwrite.

Refs: nodejs/node#13959
Bug: 
Change-Id: I158e6178f2511297899ee50ea159f574916f903f
Reviewed-on: https://chromium-review.googlesource.com/556599
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46354}
@jaimecbernardo
Copy link
Contributor Author

This seems to have landed in V8 upstream: https://chromium.googlesource.com/v8/v8/+/3bef2af6ef198b0cd1342680bf5d7d782dc71a46
Closing this PR. Thanks for everyone's help.

@refack
Copy link
Contributor

refack commented Jun 30, 2017

@refack @ofrobots Opened https://chromium-review.googlesource.com/c/556599/ to get this into V8. PTAL

Wow it landed fast, just got to it now...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v8 engine Issues and PRs related to the V8 dependency.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Build failures on Windows with 5.7-lkgr
6 participants