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

test: build test add-ons like third-party add-ons #12231

Closed
wants to merge 2 commits into from

Conversation

bnoordhuis
Copy link
Member

@bnoordhuis bnoordhuis commented Apr 5, 2017

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: #11628
CI: https://ci.nodejs.org/job/node-test-pull-request/7225/

@nodejs-github-bot nodejs-github-bot added build Issues and PRs related to build files or the CI. doc Issues and PRs related to the documentations. tools Issues and PRs related to the tools directory. windows Issues and PRs related to the Windows platform. labels Apr 5, 2017
Makefile Outdated
test: all
$(MAKE) build-addons
$(MAKE) build-addons-napi
test: build-addons
Copy link
Member Author

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);
Copy link
Contributor

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';
Copy link
Contributor

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?

@danbev danbev mentioned this pull request Apr 5, 2017
2 tasks
@mscdex mscdex added addons Issues and PRs related to native addons. test Issues and PRs related to the tests. and removed build Issues and PRs related to build files or the CI. doc Issues and PRs related to the documentations. windows Issues and PRs related to the Windows platform. labels Apr 5, 2017
Copy link
Member

@mhdawson mhdawson left a 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.

@bnoordhuis
Copy link
Member Author

Remember that time when my pull request worked on Windows on the first try? That's right, me neither...

LINK : fatal error LNK1181: cannot open input file 'c:\workspace\node-test-binary-windows\RUN_SUBSET\0\VS_VERSION\vs2015\label\win2008r2\test\addons\Release\node.lib' [c:\workspace\node-test-binary-windows\RUN_SUBSET\0\VS_VERSION\vs2015\label\win2008r2\test\gc\build\binding.vcxproj]

node-gyp looks for node.lib in a hard-coded (in lib/build.js) location relative to --nodedir=.... Needs more bovine coiffure.

(yak shaving)

Copy link
Member

@richardlau richardlau left a 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?

Copy link
Member

@richardlau richardlau left a 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?

@refack
Copy link
Contributor

refack commented Apr 14, 2017

All the red lines (not red tests) make me so warm and fuzzy inside 😻

tools/install.py Outdated Show resolved Hide resolved
@refack
Copy link
Contributor

refack commented Apr 14, 2017

I'm not really sure where commit eebfadc ended up but it's a solution for passing on windows

@refack
Copy link
Contributor

refack commented Apr 14, 2017

@refack
Copy link
Contributor

refack commented Apr 14, 2017

Well it's green where it counts https://ci.nodejs.org/job/node-test-binary-windows/7690/ 🤷

@bnoordhuis
Copy link
Member Author

Rebased and included a simplified version of @refack's fix. Not sure yet how I feel about installing node.lib to $(PREFIX)/node/Release but I suppose it doesn't matter much because we don't otherwise use install.py on Windows.

CI: https://ci.nodejs.org/job/node-test-pull-request/7511/

Please could you also remove the relative include_dirs from test/addons/zlib-binding/binding.gyp?

Done.

Also test/addons/include should be added to .gitignore?

I'm not sure why but it doesn't show up with git status. It's not because of an exclusion in my global .gitignore, that I checked by moving it out of the way.

@bnoordhuis
Copy link
Member Author

Well, that clearly didn't work. The ARM addons buildbot is passing an Intel-only flag to V8:

g++ '-DV8_TARGET_ARCH_ARM' '-DENABLE_DISASSEMBLER' '-DV8_I18N_SUPPORT' '-DUSE_EABI_HARDFLOAT=1' -I../deps/v8  -pthread -Wall -Wextra -Wno-unused-parameter -fno-strict-aliasing -m32 -fdata-sections -ffunction-sections -O3 -O3 -fno-omit-frame-pointer -fno-rtti -fno-exceptions -std=gnu++0x -MMD -MF /home/iojs/build/workspace/node-test-binary-arm/out/Release/.deps//home/iojs/build/workspace/node-test-binary-arm/out/Release/obj.host/v8_libbase/deps/v8/src/base/bits.o.d.raw   -c -o /home/iojs/build/workspace/node-test-binary-arm/out/Release/obj.host/v8_libbase/deps/v8/src/base/bits.o ../deps/v8/src/base/bits.cc
g++: error: unrecognized command line option ‘-m32’
deps/v8/src/v8_libbase.host.mk:112: recipe for target '/home/iojs/build/workspace/node-test-binary-arm/out/Release/obj.host/v8_libbase/deps/v8/src/base/bits.o' failed

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/

@refack
Copy link
Contributor

refack commented Apr 19, 2017

Not sure yet how I feel about installing node.lib to $(PREFIX)/node/Release

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 GYP authors indutny/gyp.js#37

image

@refack
Copy link
Contributor

refack commented Apr 19, 2017

https://ci.nodejs.org/job/node-test-commit-windows-fanned/8427/

Copy link
Member

@richardlau richardlau left a 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.

@refack refack mentioned this pull request Apr 19, 2017
2 tasks
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
@BridgeAR
Copy link
Member

@bnoordhuis this needs a rebase.

@BridgeAR BridgeAR added the stalled Issues and PRs that are stalled. label Sep 8, 2017
@BridgeAR
Copy link
Member

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

@BridgeAR
Copy link
Member

Closing this due to a long inactivity and no response.

@bnoordhuis please reopen if you want to follow up on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addons Issues and PRs related to native addons. stalled Issues and PRs that are stalled. test Issues and PRs related to the tests. tools Issues and PRs related to the tools directory.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants