-
Notifications
You must be signed in to change notification settings - Fork 30.2k
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
build: fix cctest build failure in Windows #21228
Conversation
I've verified the change on Windows 2016 and Ubuntu 16.04. |
@nodejs/platform-windows @nodejs/build @nodejs/testing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but have some stuff to discuss
node.gyp
Outdated
@@ -920,6 +920,143 @@ | |||
'node_dtrace_provider', | |||
], | |||
|
|||
'variables': { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why 2 levels?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it because of condition evaluation order.
In that case it's also possible to >
or "late variable expansion operator", or just put a comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
because the only variables we need in cctest target are var_defines
and dep_objs
. Other variables are just intermediate. I can flatten them if variable scope is minor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@refack after trying to flatten the variables, I need to use >
for late variable expansion and I found it's easy to get confused. I'd prefer 2 level variable and I will put a comment there. how do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Comment is totally reasonable, but IMHO it's needed since it's a non-trivial pattern.
node.gyp
Outdated
], | ||
'conditions': [ | ||
[ 'node_use_openssl=="true"', { | ||
'var_defines+': [ 'HAVE_OPENSSL=1' ], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So GYP has default list appending semantics so no need for the +
suffix
+
just means "prepend"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ran into some issues when I didn't use +
sign in other place. In this case, I can remove it.
node.gyp
Outdated
'variables': { | ||
'obj_path': '<(obj_dir)/<(node_lib_target_name)/src', | ||
'obj_gen_path': '<(obj_dir)/<(node_lib_target_name)/gen', | ||
'obj_insp_path': '<(obj_dir)/<(node_lib_target_name)/src/inspector', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's go with obj_inspetor_path
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure!
node.gyp
Outdated
'dep_objs+': [ | ||
'<(obj_path)<(obj_separator)node_crypto.<(obj_suffix)', | ||
'<(obj_path)<(obj_separator)node_crypto_bio.<(obj_suffix)', | ||
'<(obj_path)<(obj_separator)' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO this could be kept on one line (it's not the only >80 line anyway). But others may disagree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realized there are other >80 lines. however, let me follow the convention :-).
node.gyp
Outdated
], | ||
'defines': [ | ||
'HAVE_INSPECTOR=1', | ||
'test/cctest/test_inspector_socket_server.cc', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why can't we merge these lists?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
merge? can you elaborate it more?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are you talking about merging this into variables
? I don't know sources
is available inside variables
. If yes, I will merge them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@refack I can't access sources
inside variables
. then what do you mean by merge?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just that having the condition in multiple point makes it hard to grok.
So maybe define a conditionally filled variable
'node_inspector_sources' : [],
...
['v8_enable_inspector==1', {
'node_inspector_sources' : [
'test/cctest/test_inspector_socket.cc',
'test/cctest/test_inspector_socket_server.cc',
'<@(node_inspector_generated_sources)',
]
Then here (or anywhere else where sources
if appended) just have an unconditional
'sources': [ '>@(node_inspector_sources)']
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. I can merge them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@refack I found gyp throws an error when the variable is an empty array (./configure --without-inspector
). Therefore, I need to preload the sources
in cctest target into that new variable: var_sources
. Same as var_defines
.
Looks good in general, left some comments and questions. Resume CI: https://ci.nodejs.org/job/node-test-commit/19141/ |
b2a4611
to
13d7c48
Compare
13d7c48
to
748464b
Compare
rebase the code and new CI: https://ci.nodejs.org/job/node-test-commit/19311/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR basically reverts 30f89df from a few months ago and (re)introduces a lot of duplication.
cctest needs to access some internal APIs in node core.
I'd say a better way forward is to identify those internal APIs and decide on a case-by-case basis what to do with them. Can you list them?
I could also live with disabling cctest for shared library builds; the static build gives good enough coverage.
Another solution: introduce a |
@yhwang What’s the status here? |
@addaleax sorry for the lack of activity for this one. I was not able to have time handle this last month. Based on @bnoordhuis 's comment. I will disable the cctest in Windows when building shared lib. For those internal APIs that are needed by cctest, I think introducing a |
@yhwang thanks for the update, makes sense to me! |
cctest depends on some internal APIs which don't declare `__declspec(dllexport)` and causes build failure when building node as shared lib on Windows. Since we already have good test coverage in static lib, we decide to skip the cctest in shared lib build on Windows. Signed-off-by: Yihong Wang <yh.wang@ibm.com>
748464b
to
0ec2e1d
Compare
@bnoordhuis @refack I completely removed my original change and just skip cctest target in the new change based on the feedback. Please review the change again. Thanks. |
ping @bnoordhuis @refack @danbev . for now, I just disable the cctest on Windows when building shared lib. Let's discuss re-enabling it in another issue if needed. |
Ping... any updates on this one? |
I updated the change based on the comments and wait for review/comment. after the update, I haven't received any feedback yet. |
I'm fine with the current workaround... |
@bnoordhuis 's review is for old change. let me dismiss his old review |
CI is green |
Landed in 29cf335 |
cctest depends on some internal APIs which don't declare `__declspec(dllexport)` and causes build failure when building node as shared lib on Windows. Since we already have good test coverage in static lib, we decide to skip the cctest in shared lib build on Windows. Signed-off-by: Yihong Wang <yh.wang@ibm.com> PR-URL: #21228 Reviewed-By: Refael Ackermann <refack@gmail.com>
cctest depends on some internal APIs which don't declare `__declspec(dllexport)` and causes build failure when building node as shared lib on Windows. Since we already have good test coverage in static lib, we decide to skip the cctest in shared lib build on Windows. Signed-off-by: Yihong Wang <yh.wang@ibm.com> PR-URL: #21228 Reviewed-By: Refael Ackermann <refack@gmail.com>
cctest depends on some internal APIs which don't declare `__declspec(dllexport)` and causes build failure when building node as shared lib on Windows. Since we already have good test coverage in static lib, we decide to skip the cctest in shared lib build on Windows. Signed-off-by: Yihong Wang <yh.wang@ibm.com> PR-URL: #21228 Reviewed-By: Refael Ackermann <refack@gmail.com>
cctest depends on some internal APIs which don't declare `__declspec(dllexport)` and causes build failure when building node as shared lib on Windows. Since we already have good test coverage in static lib, we decide to skip the cctest in shared lib build on Windows. Signed-off-by: Yihong Wang <yh.wang@ibm.com> PR-URL: #21228 Reviewed-By: Refael Ackermann <refack@gmail.com>
cctest depends on some internal APIs which don't declare `__declspec(dllexport)` and causes build failure when building node as shared lib on Windows. Since we already have good test coverage in static lib, we decide to skip the cctest in shared lib build on Windows. Signed-off-by: Yihong Wang <yh.wang@ibm.com> PR-URL: nodejs#21228 Reviewed-By: Refael Ackermann <refack@gmail.com>
cctest depends on some internal APIs which don't declare `__declspec(dllexport)` and causes build failure when building node as shared lib on Windows. Since we already have good test coverage in static lib, we decide to skip the cctest in shared lib build on Windows. Signed-off-by: Yihong Wang <yh.wang@ibm.com> Backport-PR-URL: #25758 PR-URL: #21228 Reviewed-By: Refael Ackermann <refack@gmail.com>
cctest needs to access some internal APIs in node core. Putting
node_lib_target_name as dependency would causes linking error when
node_lib is built as shared lib in Windows. The reason being is
those internal APIs don't have
__declspec(dllexport)
. For cctestwe still need to specify individual obj files and link them instead
of node_lib. In Windows, changes of the dependencies in
libraries
trigger the cctest to rebuild. However, in Linux platforms, it
doesn't work. Instead, need to put obj dependencies into
sources
.Signed-off-by: Yihong Wang yh.wang@ibm.com
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes