-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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,tools: refactor build config into config.json #25798
Conversation
/CC @nodejs/build-files @nodejs/python @hashseed |
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 would need to be added to make clean
?
@@ -272,8 +276,13 @@ def AddModule(module, source): | |||
if name.endswith('.gypi'): | |||
# Currently only config.gypi is allowed | |||
assert name == 'config.gypi' | |||
lines = re.sub(r'\'true\'', 'true', lines) | |||
lines = re.sub(r'\'false\'', 'false', lines) | |||
config_filename = str(name).replace('gypi', 'json') |
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.
Why not just pass config.json to js2c in node.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.
For the time being I'm assuming 1:1 correspondence, and I want to keep the embedded config_raw
data exactly the same using:
https://github.com/nodejs/node/blob/c663277042ed56a221bfbb25b5acf18a1ce2fdbd/tools/js2c.py#L285
So the tight coupling is there anyway...
On a second thought...@bnoordhuis suggested replacing config.gypi with something closer to JavaScript (in stead of closer to Python) in #24816 , can't we just replace config.gypi with config.json, or does that break anybody? |
Since |
@refack If it's just for preserving the format of process.config, we can just restore it back in bootstrap/node.js after parsing it though?
I am going to be -1 if we are going to add yet another property to process.. |
BTW, I think this breaks Umm...wait, we even distribute |
Yep... |
@refack I believe if we do this in small steps, this commit simply breaks the releases if landed as-is without a follow-up landed in time? |
Yes, sorry. I Do consider those as bugs and I'll fix them until everything works as at was. To the clear the goal of this PR is to have the "interesting" parts of
|
Can't we just rename |
P.S. I fixed
IMHO we need to start with getting rid of the cruft... For example what's left now in # Do not edit. Generated by the configure script.
{ 'target_defaults': { 'cflags': [],
'default_configuration': 'Release',
'defines': [],
'include_dirs': [],
'libraries': []},
'variables': { 'includes': ['config.json']}} but the scope of where that cruft is required to keep thing from breaking need to be mapped out... RE you twitter comment, I agree that |
@@ -173,6 +166,7 @@ def ignore_inspector_headers(files, dest): | |||
action([ | |||
'common.gypi', | |||
'config.gypi', | |||
'config.json', |
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.
Does any downstream rely on the variables being in config.gypi
instead of being included? (Not sure who to ping but I guess this could make the PR semver-major?)
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.
Can't we just recreate config.gypi in this script? Or does that defeat the purpose of this PR if there is an inconsistency between what's generated in the build and what gets distributed in the tarballs?
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.
I have considered that. Since they are both created by ./configure
we could do that to solve this if we find it's a problem.
I wanted to do it like this to see if we can map the scope by looking for things that break.
(P.S. if we decide to make this semver-major, then I guess it would make sense to add the deprecation of process.config
here)
tools/js2c.py
Outdated
config = ReadFile(config_filename) | ||
config = re.sub(r'\'true\'', 'true', config) | ||
config = re.sub(r'\'false\'', 'false', config) | ||
config_definition = GetDefinition('build_config', lines) |
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.
Following the convention this should be build_config_raw
Also keep in mind that there are userland modules that do weird things with |
Ohh I just remembered why we have We could still keep it internal |
669c6d9
to
23b0104
Compare
Ping @refack this failed across the board and it requires rebasing. |
Ping @refack |
Should we close this one? |
8ae28ff
to
2935f72
Compare
This has not been worked on in a while and is out of date. Closing. |
First step in a process to normalize and formalize
process.config
and allow more generic consumption of the build config by other tools asconfig.json
.Ref: https://mobile.twitter.com/hashseed/status/1090284584116371462
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes