-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
test: build test add-ons like third-party add-ons #12231
Conversation
Makefile
Outdated
test: all | ||
$(MAKE) build-addons | ||
$(MAKE) build-addons-napi | ||
test: build-addons |
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 does the configure + build dance before running any of the JS tests. Probably should be moved but I kept it as close as possible to the existing order for now.
next(); | ||
}); | ||
|
||
console.log(command, 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.
Could console.log call perhaps be removed in favour of just printing console.log(`building addon ${path}`);
before 9864090#diff-31601f8dbf082ea61af036efe1e9c00dR54?
command]; | ||
|
||
const env = Object.assign({}, process.env); | ||
env.MAKEFLAGS = '-j1'; |
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.
Perhaps --silent
could be added to this to avoid extra output?
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 as long as ci is green.
Remember that time when my pull request worked on Windows on the first try? That's right, me neither...
node-gyp looks for node.lib in a hard-coded (in lib/build.js) location relative to (yak shaving) |
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.
Please could you also remove the relative include_dirs
from test/addons/zlib-binding/binding.gyp
?
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.
Also test/addons/include
should be added to .gitignore
?
All the red lines (not red tests) make me so warm and fuzzy inside 😻 |
I'm not really sure where commit eebfadc ended up but it's a solution for passing on windows |
Well it's green where it counts https://ci.nodejs.org/job/node-test-binary-windows/7690/ 🤷 |
eebfadc
to
1f56dcf
Compare
Rebased and included a simplified version of @refack's fix. Not sure yet how I feel about installing node.lib to CI: https://ci.nodejs.org/job/node-test-pull-request/7511/
Done.
I'm not sure why but it doesn't show up with |
1f56dcf
to
6dbb055
Compare
Well, that clearly didn't work. The ARM addons buildbot is passing an Intel-only flag to V8:
Some weird interaction with the distributed build perhaps? One more try in case it was a fluke, I need to test the fixed Windows fix anyway: https://ci.nodejs.org/job/node-test-pull-request/7513/ |
Not sure either, but it kinda makes sense, since otherwise the headers are only half useful (unless build target was a shared_lib). Ref: a short discussion about this by the |
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 if CI passes.
Until now we built add-ons by pointing node-gyp at the src/ directory. We've had at least one DOA release where add-ons were broken because of a header dependency issue that wasn't caught because we build our test add-ons in a non-standard way. This commit does the following: * Use tools/install.py to install the headers to test/addons/include. * Add a script to build everything in test/addons. * Remove the pile-up of hacks from the Makefile. The same logic is applied to test/addons-napi and test/gc. Everything is done in parallel as much as possible to speed up builds. Ideally, we derive the level of parallelism from MAKEFLAGS but it lacks the actual `-j<n>` flag. That's why it simply spawns as many processes as there are processors for now. The exception is tools/doc/addon-verify.js: I switched it to synchronous logic to make it easy to use from another script. Since it takes no time at all to do its work, that seemed like a reasonable trade-off to me. Refs: nodejs#11628
ce81a1b
to
4d56418
Compare
@bnoordhuis this needs a rebase. |
@bnoordhuis I think this mainly just needs a rebase and is otherwise good to go? It is stalled since quite a while and I would go ahead and close this in a couple of days otherwise. |
Closing this due to a long inactivity and no response. @bnoordhuis please reopen if you want to follow up on this. |
Until now we built add-ons by pointing node-gyp at the src/ directory.
We've had at least one DOA release where add-ons were broken because of
a header dependency issue that wasn't caught because we build our test
add-ons in a non-standard way.
This commit does the following:
The same logic is applied to test/addons-napi and test/gc.
Everything is done in parallel as much as possible to speed up builds.
Ideally, we derive the level of parallelism from MAKEFLAGS but it lacks
the actual
-j<n>
flag. That's why it simply spawns as many processesas there are processors for now.
The exception is tools/doc/addon-verify.js: I switched it to synchronous
logic to make it easy to use from another script. Since it takes no time
at all to do its work, that seemed like a reasonable trade-off to me.
Refs: #11628
CI: https://ci.nodejs.org/job/node-test-pull-request/7225/