★ wanayoo — archive 1999 https://github.com/nodejs/node/pull/23426Nouvelle recherche | Portail wanayoo
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
Member

@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

@refack
Copy link
Member Author

@refack refack commented Oct 11, 2018

@refack refack self-assigned this Oct 11, 2018
@refack refack added the addons label Oct 11, 2018
@refack
Copy link
Member Author

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

@addaleax addaleax commented Oct 11, 2018

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

@refack
Copy link
Member Author

@refack 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 label Oct 11, 2018
@richardlau
Copy link
Member

@richardlau richardlau commented Oct 11, 2018

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

@addaleax
Copy link
Member

@addaleax addaleax commented Oct 11, 2018

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
Member Author

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

@thefourtheye thefourtheye Oct 11, 2018

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
Member Author

@refack refack Oct 11, 2018

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
Member Author

@refack refack Oct 11, 2018

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

@thefourtheye thefourtheye Oct 11, 2018

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

@richardlau richardlau commented Oct 11, 2018

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

@addaleax addaleax commented Oct 11, 2018

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

@jkrems
Copy link
Contributor

@jkrems 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
Member Author

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

@refack
Copy link
Member Author

@refack refack commented Oct 13, 2018

@joyeecheung joyeecheung dismissed their stale review Oct 14, 2018

This could break addons with -Werror

@joyeecheung
Copy link
Member

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

@refack
Copy link
Member Author

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

@addaleax addaleax commented Oct 14, 2018

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
Member Author

@refack 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
Member Author

@refack 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
Member Author

@refack refack commented Oct 24, 2018

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 Oct 24, 2018
@refack refack force-pushed the warn-addons-on-v8-imminent-deprecation branch from c159847 to af968e2 Compare Nov 4, 2018
@refack
Copy link
Member Author

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

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 Nov 5, 2018
@refack refack merged commit 765766b into nodejs:master Nov 5, 2018
1 of 2 checks passed
@refack refack added the landed label Nov 5, 2018
@refack refack deleted the warn-addons-on-v8-imminent-deprecation branch Nov 5, 2018
@refack refack removed the request for review from addaleax Nov 5, 2018
@refack refack removed their assignment Nov 6, 2018
@@ -503,7 +513,18 @@
'ldflags': [
'-Wl,--export-dynamic',
],
}]
}],
['node_shared_openssl!="true"', {
Copy link
Contributor

@sam-github sam-github Jan 4, 2019

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

@sam-github sam-github Jan 4, 2019

Choose a reason for hiding this comment

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

cf. #25135

@BethGriggs BethGriggs mentioned this pull request Mar 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

9 participants