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 common defines #23426

Merged

Conversation

refack
Copy link
Contributor

@refack refack commented Oct 11, 2018

  • V8_DEPRECATION_WARNINGS is here for explicity. It is already defined
    in node.gypi, and addon.gypi.
  • V8_IMMINENT_DEPRECATION_WARNINGS added to warn addons authors.
  • OPENSSL_THREADS apears in the openSSL .h files, and was only
    defined via GYP for the node build.

Refs: #23122
Refs: #23414 (comment)
Fixes: #23167

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • documentation is changed or added
  • commit message follows commit guidelines
@nodejs-github-bot nodejs-github-bot added the build Issues and PRs related to build files or the CI. label Oct 11, 2018
@refack
Copy link
Contributor Author

refack commented Oct 11, 2018

/CC @nodejs/build-files @nodejs/addon-api @nodejs/node-gyp

@refack refack self-assigned this Oct 11, 2018
@refack refack added the addons Issues and PRs related to native addons. label Oct 11, 2018
@refack
Copy link
Contributor Author

refack commented Oct 11, 2018

Currently this will cause a lot of deprecation warning for the node build:

Number Method
3 v8::Date::New #23288
2 v8::Function::Call
29 v8::Object::Get
1 v8::Object::GetPropertyNames
147 v8::Object::Set
2 v8::String::NewFromTwoByte
2 v8::Value::ToObject
(2) v8::WasmCompiledModule::CallerOwnedBuffer

So we can consider unsetting V8_IMMINENT_DEPRECATION_WARNINGS for the node GYP target until we fix our code.

@addaleax
Copy link
Member

As explained in #23167, I don’t think the OpenSSL defines should or need to end up here.

@refack
Copy link
Contributor Author

refack commented Oct 11, 2018

As explained in #23167, I don’t think the OpenSSL defines should or need to end up here.

That does make sense, but ATM we do define it for the node build:

(and every other architecture), so this just synchronizes how we build, and what we export to addons.

/CC @nodejs/crypto should it be undefined for the node build?

@refack refack added the crypto Issues and PRs related to the crypto subsystem. label Oct 11, 2018
@richardlau
Copy link
Member

If we're going to suddenly enable warnings for native addons, semver-major?

@refack refack added the semver-major PRs that contain breaking changes and should be released in the next major version. label Oct 11, 2018
@addaleax
Copy link
Member

If we're going to suddenly enable warnings for native addons, semver-major?

We can decide to do that, but I’d not consider it semver-major. Deprecation warnings in C++ are kind of different from runtime deprecations in JS, and we’ve been treating these as semver-minor so far.

@refack
Copy link
Contributor Author

refack commented Oct 11, 2018

If we're going to suddenly enable warnings for native addons, semver-major?

It would be advantageous to have this in node11

# `OPENSSL_THREADS` is defined via GYP for openSSL for all architectures.
'OPENSSL_THREADS'
'V8_DEPRECATION_WARNINGS',
'V8_IMMINENT_DEPRECATION_WARNINGS',
Copy link
Contributor

Choose a reason for hiding this comment

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

Just to understand this better, what are the differences between these two?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Example: https://github.com/nodejs/node/pull/23414/files
AFAIU V8_DEPRECATION_WARNINGS makes API points marked with V8_DEPRECATED marked [[deprecated]]
V8_IMMINENT_DEPRECATION_WARNINGS makes thant for API points marked with V8_DEPRECATE_SOON.
Similar to node's policy V8_DEPRECATED are not-recommended for use, and can be removed in the next V8 version. V8_DEPRECATE_SOON can only be demoted to V8_DEPRECATED in a next version.

/CC @hashseed, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ATM we do turn on V8_DEPRECATION_WARNINGS for node build, and native addons builds.

Copy link
Contributor

Choose a reason for hiding this comment

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

So V8_IMMINENT_DEPRECATION_WARNINGS will report DEPRECATE_SOON and V8_DEPRECATION_WARNINGS will report the normal deprecation, right?

@richardlau
Copy link
Member

If we're going to suddenly enable warnings for native addons, semver-major?

We can decide to do that, but I’d not consider it semver-major. Deprecation warnings in C++ are kind of different from runtime deprecations in JS, and we’ve been treating these as semver-minor so far.

Fair enough. I'm just mindful that the majority of users seeing these will be users installing the addons (probably as dependencies of other modules) who are unlikely to be in a position to do something about them and may be asking why they are suddenly appearing with a new version of Node.js. Maybe at least it should be called out in the release notes?

joyeecheung
joyeecheung previously approved these changes Oct 11, 2018
@addaleax
Copy link
Member

@jkrems Given nodejs/nan#811 (comment), do you maybe want to weigh in here?

@jkrems
Copy link
Contributor

jkrems commented Oct 12, 2018

@addaleax Thanks for the ping!

Fair enough. I'm just mindful that the majority of users seeing these will be users installing the addons (probably as dependencies of other modules) who are unlikely to be in a position to do something about them and may be asking why they are suddenly appearing with a new version of Node.js.

Is there any way this could not be enabled for things coming from dependencies? I don't think there's any value for 3rd party dependencies, other than causing a lot of non-actionable noise. The issue is that I've seen a lot of teams we support start writing hacks and workarounds to get rid of these warnings if they originated in code they don't control. Even worse: warnings that cannot be directly addressed drown out other, more critical issues and can send people on wild goose chases.

In other words: Can we make sure that the people who see these new warnings are mostly (or even only) the people who can actually fix them?

@refack
Copy link
Contributor Author

refack commented Oct 12, 2018

In other words: Can we make sure that the people who see these new warnings are mostly (or even only) the people who can actually fix them?

I think we can but we'll need to patch node-gyp.

@joyeecheung joyeecheung dismissed their stale review October 14, 2018 22:48

This could break addons with -Werror

@joyeecheung
Copy link
Member

Hmm, I just learned that some addons use -Werror, this would break them so if we are actually turning the flags on.

@refack
Copy link
Contributor Author

refack commented Oct 14, 2018

Hmm, I just learned that some addons use -Werror, this would break them so if we are actually turning the flags on.

IMHO that's a good thing, it will best way to notify the authors ahead of time or

  1. They could 'defines!': [ 'V8_IMMINENT_DEPRECATION_WARNINGS' ]
  2. Or they will break on next V8 tick, when IMMINENT turns to DEPRECATION
@addaleax
Copy link
Member

That’s … interesting. @joyeecheung Do you know how much “some addons” is?

If we do enable warnings for those, every deprecation would already be as bad as the breaking change itself, which completely defeats the purpose of deprecations…

@refack
Copy link
Contributor Author

refack commented Oct 15, 2018

some addons use -Werror

What happens when you combine -Werror -Wno-deprecated-declarations...

I'll go check...

@refack
Copy link
Contributor Author

refack commented Oct 16, 2018

BTW what about we build Node with -Werror?

Much work to be done for that. (and we'll need to exclude all the /deps/).
BTW: I tried that 4 years ago nodejs/node-v0.x-archive#8485 👴

@refack
Copy link
Contributor Author

refack commented Oct 24, 2018

/CC @nodejs/release @nodejs/addon-api PTAL

common.gypi Outdated Show resolved Hide resolved
common.gypi Outdated Show resolved Hide resolved
@refack refack force-pushed the warn-addons-on-v8-imminent-deprecation branch from a1060a4 to c159847 Compare October 24, 2018 23:46
@refack refack force-pushed the warn-addons-on-v8-imminent-deprecation branch from c159847 to af968e2 Compare November 4, 2018 21:08
@refack
Copy link
Contributor Author

refack commented Nov 4, 2018

Sample CI: https://ci.nodejs.org/job/node-test-pull-request-lite-pipeline/1491/

@nodejs/tsc PTAL:
This is a semver-major change since it turns on compilation time deprecation warnings for V8 APIs annotated with V8_DEPRECATE_SOON for node-core and native-addons built with node-gyp.
In addition, for native-addons, it also turns on compilation warnings for V8 APIs annotated with V8_DEPRECATED.
(Both of these can be turned off by addon authors - Ref: nodejs/nan#811 (comment))

ATM this will produce a significant amount of new warning when compiling node. Last audit gross number is 673, of which 175 are unique.

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

Copy link
Member

@joyeecheung joyeecheung left a comment

Choose a reason for hiding this comment

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

Let's land it first - at least it will take a while to actually reach the addon ecosystem, in the meantime we can fix our warnings first

* `V8_DEPRECATION_WARNINGS` is here for explicity. It is already defined
  in `node.gypi`, and `addon.gypi`.
* `V8_IMMINENT_DEPRECATION_WARNINGS` added to warn addons authors.
* `OPENSSL_THREADS` apears in the openSSL `.h` files, and was only
  defined via GYP for the node build.

PR-URL: nodejs#23426
Fixes: nodejs#23167
Refs: nodejs#23122
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
@refack refack force-pushed the warn-addons-on-v8-imminent-deprecation branch from af968e2 to 765766b Compare November 5, 2018 02:52
@refack refack merged commit 765766b into nodejs:master Nov 5, 2018
@refack refack added the landed label Nov 5, 2018
@refack refack deleted the warn-addons-on-v8-imminent-deprecation branch November 5, 2018 02:54
@refack refack removed the request for review from addaleax November 5, 2018 02:54
@refack refack removed their assignment Nov 6, 2018
@@ -503,7 +513,18 @@
'ldflags': [
'-Wl,--export-dynamic',
],
}]
}],
['node_shared_openssl!="true"', {
Copy link
Contributor

Choose a reason for hiding this comment

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

@refack You suggested that to avoid OpenSSL flags being passed to icu (and thus triggering an icu rebuild when switching between shared/non-shared openssl, a change that doesn't effect icu), I could "Add OPENSSL_THREADS to the else clause.", but I'm not sure what you mean by else clause here. Can you elaborate, and I'll make the change and test it?

Copy link
Contributor

Choose a reason for hiding this comment

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

cf. #25135

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. build Issues and PRs related to build files or the CI. crypto Issues and PRs related to the crypto subsystem. semver-major PRs that contain breaking changes and should be released in the next major version.
9 participants