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

build: add node_module_version to config.gypi #7808

Closed
wants to merge 2 commits into from

Conversation

saper
Copy link

@saper saper commented Jul 20, 2016

Enable targetting of a different node version than
the currently running one when building binary modules.

This is extracted from 410296c37

PR-URL: nodejs/node-gyp#855

Work around spec violations in V8 where it checks that `this == NULL`.
GCC 6 started exploiting this particular kind of UB, resulting in
runtime crashes.

Fixes: nodejs#6724
PR-URL: nodejs#6738
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michaël Zasso <mic.besace@gmail.com>
assert(process.config.variables.hasOwnProperty('node_module_version'));

// ensure that `node_module_version` is an Integer > 0
assert(!Number.isNaN(parseInt(process.config.variables.node_module_version)))
Copy link
Member

Choose a reason for hiding this comment

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

Missing ;

@bnoordhuis
Copy link
Member

LGTM with style nit.

cc @nodejs/lts

@Fishrock123
Copy link
Contributor

I'm not sure we'd actually backport this kinda thing to v0.10... @nodejs/lts

@bnoordhuis
Copy link
Member

I commented on that here. I think a case for an exception can be made here.

@saper
Copy link
Author

saper commented Jul 20, 2016

For example at https://github.com/sass/node-sass/releases/tag/v3.8.0 we are building binaries for all known node modules versions. It would be easier to support and cross-compile to older node versions if they need not be installed. Having the same interface in the config.gypi would be really cool, without resorting to workarounds like manual parsing of the node header files. Having it only in the newest version kind of defeats its purpose - it works only for the current and the future versions. For legacy versions, one would need to resort to manual version guessing.

One uses always the latest v0.10, v0.12 etc. headers and config.gypi files anyway, so if this change makes it into, say, v0.10.47 and v0.12.16, I don't need to bother about older 0.10 and 0.12 versions, since the binaries will work there, too.

@rvagg
Copy link
Member

rvagg commented Jul 20, 2016

@saper you could hardwire values for 0.10 and 0.12 though, right? those are fixed numbers and not going to change (same with every other major but I take the point about it being easier into the future).

@saper saper force-pushed the node_module_version/v0.10 branch 2 times, most recently from 9ff899f to d108c3b Compare July 20, 2016 12:44
@jasnell
Copy link
Member

jasnell commented Aug 1, 2016

I've no objections to backporting this to v0.10 with the caveat that anything that depends on process.config is inherently flaky.

This PR LGTM.

@jasnell
Copy link
Member

jasnell commented Aug 4, 2016

@nodejs/lts ... any additional thoughts? I'm inclined to land unless there are objections.

@saper
Copy link
Author

saper commented Aug 4, 2016

Should I prepare pull requests for 0.12 and LTS?

@bnoordhuis
Copy link
Member

@saper Yes, go ahead. One small style nit: can you capitalize the comments in the test?

@saper saper force-pushed the node_module_version/v0.10 branch from d108c3b to 4c24cb3 Compare August 8, 2016 23:03
@saper
Copy link
Author

saper commented Aug 8, 2016

Nit fixed, thank you.

@jasnell
Copy link
Member

jasnell commented Aug 18, 2016

ping @bnoordhuis ... does this LGTY?

@bnoordhuis
Copy link
Member

The test could use assert.equal() when comparing the numbers. LGTM either way though.

To who lands this: s/Provide/provide/ in the title of the commit and maybe drop the quotes so it fits in 50 columns.

@saper saper force-pushed the node_module_version/v0.10 branch from cb47e37 to 3f7a52b Compare August 18, 2016 20:52
@jasnell
Copy link
Member

jasnell commented Aug 18, 2016

Oh, right, didn't notice that this was against v0.10 directly. Either we can open a new PR against v0.10-staging or we can roll the dice with GitHubs new PR-retargeting feature.

@saper saper changed the base branch from v0.10 to v0.10-staging August 18, 2016 22:15
@saper saper force-pushed the node_module_version/v0.10 branch from 3f7a52b to 7299eac Compare August 18, 2016 22:16
@saper
Copy link
Author

saper commented Aug 18, 2016

@jasnell just tried that and I think it might have worked (I got 5 commits after retarget so I have pushed a cherry-picked commit)

@@ -0,0 +1,10 @@
'use strict';
require('../common');
var assert = require('assert');
Copy link
Member

@jasnell jasnell Aug 18, 2016

Choose a reason for hiding this comment

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

can you use const here please :-)

Copy link
Member

Choose a reason for hiding this comment

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

ugh.. ha! nevermind... v0.10.... silly me

Copy link
Author

Choose a reason for hiding this comment

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

Do you think we might actually want to add const in the current trunk?

var assert = require('assert');

Copy link
Member

Choose a reason for hiding this comment

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

We should be using const in master, definitely, but by itself that's not enough of a reason to update the test case if it's not using const already. Best to leave it unless there are other changes to make.


// Ensure that `node_module_version` is an Integer
assert(!Number.isNaN(parseInt(process.config.variables.node_module_version)));
assert.equal(process.config.variables.node_module_version, 11);
Copy link
Member

Choose a reason for hiding this comment

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

assert.strictEqual() here instead of assert.equal()

Copy link
Member

Choose a reason for hiding this comment

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

Apologies, I said assert.equal() because I had a fuzzy notion that strictEqual() doesn't exist in v0.10. I was probably thinking of deepStrictEqual().

Copy link
Author

Choose a reason for hiding this comment

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

No problem, happy to learn more about differences between node engines.

Enable targetting of a different node version than
the currently running one when building binary modules.

Based on nodejs/node@410296c37

PR-URL: nodejs#7808
Ref: nodejs/node-gyp#855
@saper saper force-pushed the node_module_version/v0.10 branch from 7299eac to 6a47a07 Compare August 18, 2016 22:39
saper added a commit to saper/node that referenced this pull request Aug 18, 2016
Enable targetting of a different node version than
the currently running one when building binary modules.

Based on nodejs/node@410296c37

PR-URL: nodejs#8027
Ref: nodejs#7808
Ref: nodejs/node-gyp#855
@saper
Copy link
Author

saper commented Aug 18, 2016

@jasnell voilà!

saper added a commit to saper/node that referenced this pull request Aug 19, 2016
Enable targetting of a different node version than
the currently running one when building binary modules.

Based on nodejs/node@410296c37

PR-URL: nodejs#8171
Ref: nodejs#8027
Ref: nodejs#7808
Ref: nodejs/node-gyp#855
jasnell pushed a commit that referenced this pull request Aug 22, 2016
Enable targetting of a different node version than
the currently running one when building binary modules.

Based on 410296c37

PR-URL: #8171
Ref: #8027
Ref: #7808
Ref: nodejs/node-gyp#855
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
MylesBorins pushed a commit that referenced this pull request Sep 28, 2016
Enable targetting of a different node version than
the currently running one when building binary modules.

Based on 410296c37

PR-URL: #8171
Ref: #8027
Ref: #7808
Ref: nodejs/node-gyp#855
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
rvagg pushed a commit that referenced this pull request Oct 18, 2016
Enable targetting of a different node version than
the currently running one when building binary modules.

Based on 410296c37

PR-URL: #8171
Ref: #8027
Ref: #7808
Ref: nodejs/node-gyp#855
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
MylesBorins pushed a commit that referenced this pull request Oct 26, 2016
Enable targetting of a different node version than
the currently running one when building binary modules.

Based on 410296c37

PR-URL: #8171
Ref: #8027
Ref: #7808
Ref: nodejs/node-gyp#855
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
@jasnell
Copy link
Member

jasnell commented Oct 26, 2016

@nodejs/lts... this appears to be the only still open PR based on v0.10-staging. Given that it's not likely that we'll be cutting a new v0.10, I recommend that we go ahead and close this.

@mscdex mscdex removed the v0.10 label Nov 14, 2016
saper added a commit to saper/node that referenced this pull request Dec 20, 2016
Enable targetting of a different node version than
the currently running one when building binary modules.

Based on nodejs/node@410296c37

PR-URL: nodejs#8027
Ref: nodejs#7808
Ref: nodejs/node-gyp#855
bnoordhuis pushed a commit to bnoordhuis/io.js that referenced this pull request Dec 20, 2016
Enable targetting of a different node version than
the currently running one when building binary modules.

Based on nodejs/node@410296c37

PR-URL: nodejs#8027
Ref: nodejs#7808
Ref: nodejs/node-gyp#855
@jasnell
Copy link
Member

jasnell commented Jan 6, 2017

Closing given that v0.10 is no longer actively supported

@jasnell jasnell closed this Jan 6, 2017
@saper
Copy link
Author

saper commented Jan 6, 2017

Thanks, if there will be no 0.10 release this makes no point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build Issues and PRs related to build files or the CI.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants