nodejs/node.gyp

1257 lines
38 KiB
Plaintext
Raw Normal View History

2011-08-03 17:01:30 -07:00
{
2011-08-03 23:36:27 -07:00
'variables': {
'v8_use_siphash%': 0,
'v8_trace_maps%': 0,
'v8_enable_pointer_compression%': 0,
'v8_enable_31bit_smis_on_64bit_arch%': 0,
'node_no_browser_globals%': 'false',
'node_snapshot_main%': '',
'node_use_node_snapshot%': 'false',
'node_use_v8_platform%': 'true',
'node_use_bundled_v8%': 'true',
'node_shared%': 'false',
'force_dynamic_crt%': 0,
'ossfuzz' : 'false',
'node_module_version%': '',
'node_shared_brotli%': 'false',
2012-02-26 16:02:21 -07:00
'node_shared_zlib%': 'false',
'node_shared_http_parser%': 'false',
'node_shared_cares%': 'false',
'node_shared_libuv%': 'false',
'node_shared_nghttp2%': 'false',
2011-09-05 01:01:53 +02:00
'node_use_openssl%': 'true',
'node_shared_openssl%': 'false',
'node_v8_options%': '',
'node_enable_v8_vtunejit%': 'false',
build: Updates for AIX npm support - part 1 This PR is the first step enabling support for native modules for AIX. The main issue is that unlike linux where all symbols within the Node executable are available to the shared library for a native module (npm), on AIX the symbols must be explicitly exported. In addition, when the shared library is built it must be linked using a list of the available symbols. This patch covers the changes need to: 1) Export the symbols when building the node executable 2) Generate the file listing the symbols that can be used when building the shared library. For AIX, it breaks the build process into 2 steps. The first builds a static library and then generates a node.exp file which contains the symbols from that library. The second builds the node executable and uses the node.exp file to specify which symbols should be exported. In addition, it save the node.exp file so that it can later be used in the creation of the shared library when building a native module. The following additional steps will be required in dependent projects to fully enable AIX for native modules and are being worked separately: - Updates to node-gyp to use node.exp when creating the shared library for a native module - Fixes to gyp related to copying files as covered in https://codereview.chromium.org/1368133002/patch/1/10001 - Pulling in updated gyp versions to Node and node-gyp - Pulling latest libuv These changes were done to minimize the change to other platforms by working within the existing structure to add the 2 step process for AIX without changing the process for other platforms. PR-URL: https://github.com/nodejs/node/pull/3114 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
2015-09-29 10:22:00 -04:00
'node_core_target_name%': 'node',
'node_lib_target_name%': 'libnode',
'node_intermediate_lib_type%': 'static_library',
'node_builtin_modules_path%': '',
# We list the deps/ files out instead of globbing them in js2c.py since we
# only include a subset of all the files under these directories.
# The lengths of their file names combined should not exceed the
# Windows command length limit or there would be an error.
# See https://docs.microsoft.com/en-us/troubleshoot/windows-client/shell-experience/command-line-string-limitation
2011-09-05 01:01:53 +02:00
'library_files': [
'<@(node_library_files)',
],
'deps_files': [
'deps/v8/tools/splaytree.mjs',
'deps/v8/tools/codemap.mjs',
'deps/v8/tools/consarray.mjs',
'deps/v8/tools/csvparser.mjs',
'deps/v8/tools/profile.mjs',
'deps/v8/tools/profile_view.mjs',
'deps/v8/tools/logreader.mjs',
'deps/v8/tools/arguments.mjs',
'deps/v8/tools/tickprocessor.mjs',
'deps/v8/tools/sourcemap.mjs',
'deps/v8/tools/tickprocessor-driver.mjs',
'deps/acorn/acorn/dist/acorn.js',
'deps/acorn/acorn-walk/dist/walk.js',
'<@(node_builtin_shareable_builtins)',
2011-09-05 01:01:53 +02:00
],
'node_mksnapshot_exec': '<(PRODUCT_DIR)/<(EXECUTABLE_PREFIX)node_mksnapshot<(EXECUTABLE_SUFFIX)',
'conditions': [
['GENERATOR == "ninja"', {
'node_text_start_object_path': 'src/large_pages/node_text_start.node_text_start.o'
}, {
'node_text_start_object_path': 'node_text_start/src/large_pages/node_text_start.o'
}],
[ 'node_shared=="true"', {
'node_target_type%': 'shared_library',
'conditions': [
['OS=="aix"', {
# For AIX, always generate static library first,
# It needs an extra step to generate exp and
# then use both static lib and exp to create
# shared lib.
'node_intermediate_lib_type': 'static_library',
}, {
'node_intermediate_lib_type': 'shared_library',
}],
],
}, {
'node_target_type%': 'executable',
}],
[ 'OS=="win" and '
'node_use_openssl=="true" and '
'node_shared_openssl=="false"', {
'use_openssl_def%': 1,
}, {
'use_openssl_def%': 0,
}],
],
2011-08-03 23:36:27 -07:00
},
'target_defaults': {
# Putting these explicitly here so not to depend on `common.gypi`.
# `common.gypi` need to be more general because it is used to build userland native addons.
# Refs: https://github.com/nodejs/node-gyp/issues/1118
'cflags': [ '-Wall', '-Wextra', '-Wno-unused-parameter', ],
'xcode_settings': {
'WARNING_CFLAGS': [
'-Wall',
'-Wendif-labels',
'-W',
'-Wno-unused-parameter',
'-Werror=undefined-inline',
'-Werror=extra-semi',
],
},
# Relevant only for x86.
# Refs: https://github.com/nodejs/node/pull/25852
# Refs: https://docs.microsoft.com/en-us/cpp/build/reference/safeseh-image-has-safe-exception-handlers
'msvs_settings': {
'VCLinkerTool': {
'ImageHasSafeExceptionHandlers': 'false',
},
},
'conditions': [
['OS=="aix"', {
'ldflags': [
'-Wl,-bnoerrmsg',
],
}],
['OS == "linux" and llvm_version != "0.0"', {
'libraries': ['-latomic'],
}],
],
},
2011-08-03 17:01:30 -07:00
'targets': [
{
'target_name': 'node_text_start',
'type': 'none',
'conditions': [
[ 'OS in "linux freebsd solaris" and '
'target_arch=="x64"', {
'type': 'static_library',
'sources': [
'src/large_pages/node_text_start.S'
]
}],
]
},
2011-08-03 17:01:30 -07:00
{
build: Updates for AIX npm support - part 1 This PR is the first step enabling support for native modules for AIX. The main issue is that unlike linux where all symbols within the Node executable are available to the shared library for a native module (npm), on AIX the symbols must be explicitly exported. In addition, when the shared library is built it must be linked using a list of the available symbols. This patch covers the changes need to: 1) Export the symbols when building the node executable 2) Generate the file listing the symbols that can be used when building the shared library. For AIX, it breaks the build process into 2 steps. The first builds a static library and then generates a node.exp file which contains the symbols from that library. The second builds the node executable and uses the node.exp file to specify which symbols should be exported. In addition, it save the node.exp file so that it can later be used in the creation of the shared library when building a native module. The following additional steps will be required in dependent projects to fully enable AIX for native modules and are being worked separately: - Updates to node-gyp to use node.exp when creating the shared library for a native module - Fixes to gyp related to copying files as covered in https://codereview.chromium.org/1368133002/patch/1/10001 - Pulling in updated gyp versions to Node and node-gyp - Pulling latest libuv These changes were done to minimize the change to other platforms by working within the existing structure to add the 2 step process for AIX without changing the process for other platforms. PR-URL: https://github.com/nodejs/node/pull/3114 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
2015-09-29 10:22:00 -04:00
'target_name': '<(node_core_target_name)',
'type': 'executable',
'defines': [
'NODE_ARCH="<(target_arch)"',
'NODE_PLATFORM="<(OS)"',
'NODE_WANT_INTERNALS=1',
],
'includes': [
'node.gypi'
],
'include_dirs': [
'src',
'deps/v8/include'
],
'sources': [
'src/node_main.cc'
],
'dependencies': [
'deps/histogram/histogram.gyp:histogram',
'deps/uvwasi/uvwasi.gyp:uvwasi',
],
'msvs_settings': {
'VCLinkerTool': {
'GenerateMapFile': 'true', # /MAP
'MapExports': 'true', # /MAPINFO:EXPORTS
'RandomizedBaseAddress': 2, # enable ASLR
'DataExecutionPrevention': 2, # enable DEP
'AllowIsolation': 'true',
# By default, the MSVC linker only reserves 1 MiB of stack memory for
# each thread, whereas other platforms typically allow much larger
# stack memory sections. We raise the limit to make it more consistent
# across platforms and to support the few use cases that require large
# amounts of stack memory, without having to modify the node binary.
'StackReserveSize': 0x800000,
},
},
# - "C4244: conversion from 'type1' to 'type2', possible loss of data"
# Ususaly safe. Disable for `dep`, enable for `src`
'msvs_disabled_warnings!': [4244],
'conditions': [
[ 'error_on_warn=="true"', {
'cflags': ['-Werror'],
'xcode_settings': {
'WARNING_CFLAGS': [ '-Werror' ],
},
}],
[ 'node_intermediate_lib_type=="static_library" and '
'node_shared=="true" and OS=="aix"', {
# For AIX, shared lib is linked by static lib and .exp. In the
# case here, the executable needs to link to shared lib.
# Therefore, use 'node_aix_shared' target to generate the
# shared lib and then executable.
'dependencies': [ 'node_aix_shared' ],
}, {
'dependencies': [ '<(node_lib_target_name)' ],
build: fix various shared library build issues Node.js unofficially supports a shared library variant where the main node executable is a thin wrapper around node.dll/libnode.so. The key benefit of this is to support embedding Node.js in other applications. Since Node.js 12 there have been a number of issues preventing the shared library build from working correctly, primarily on Windows: * A number of functions used executables such as `mksnapshot` are not exported from `libnode.dll` using a `NODE_EXTERN` attribute * A dependency on the `Winmm` system library is missing * Incorrect defines on executable targets leads to `node.exe` claiming to export a number of functions that are actually in `libnode.dll` * Because `node.exe` attempts to export symbols, `node.lib` gets generated causing native extensions to try to link against `node.exe` not `libnode.dll`. * Similarly, because `node.dll` was renamed to `libnode.dll`, native extensions don't know to look for `libnode.lib` rather than `node.lib`. * On macOS an RPATH is added to find `libnode.dylib` relative to `node` in the same folder. This works fine from the `out/Release` folder but not from an installed prefix, where `node` will be in `bin/` and `libnode.dylib` will be in `lib/`. * Similarly on Linux, no RPATH is added so LD_LIBRARY_PATH needs setting correctly for `bin/node` to find `lib/libnode.so`. For the `libnode.lib` vs `node.lib` issue there are two possible options: 1. Ensure `node.lib` from `node.exe` does not get generated, and instead copy `libnode.lib` to `node.lib`. This means addons compiled when referencing the correct `node.lib` file will correctly depend on `libnode.dll`. The down side is that native addons compiled with stock Node.js will still try to resolve symbols against node.exe rather than libnode.dll. 2. After building `libnode.dll`, dump the exports using `dumpbin`, and process this to generate a `node.def` file to be linked into `node.exe` with the `/DEF:node.def` flag. The export entries in `node.def` will all read ``` my_symbol=libnode.my_symbol ``` so that `node.exe` will redirect all exported symbols back to `libnode.dll`. This has the benefit that addons compiled with stock Node.js will load correctly into `node.exe` from a shared library build, but means that every embedding executable also needs to perform this same trick. I went with the first option as it is the cleaner of the two solutions in my opinion. Projects wishing to generate a shared library variant of Node.js can now, for example, ``` .\vcbuild dll package vs ``` to generate a full node installation including `libnode.dll`, `Release\node.lib`, and all the necessary headers. Native addons can then be built against the shared library build easily by specifying the correct `nodedir` option. For example ``` >npx node-gyp configure --nodedir C:\Users\User\node\Release\node-v18.0.0-win-x64 ... >npx node-gyp build ... >dumpbin /dependents build\Release\binding.node Microsoft (R) COFF/PE Dumper Version 14.29.30136.0 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file build\Release\binding.node File Type: DLL Image has the following dependencies: KERNEL32.dll libnode.dll VCRUNTIME140.dll api-ms-win-crt-string-l1-1-0.dll api-ms-win-crt-stdio-l1-1-0.dll api-ms-win-crt-runtime-l1-1-0.dll ... ``` PR-URL: https://github.com/nodejs/node/pull/41850 Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Beth Griggs <bgriggs@redhat.com> Reviewed-By: Richard Lau <rlau@redhat.com>
2022-02-04 10:12:57 +00:00
'conditions': [
['OS=="win" and node_shared=="true"', {
'dependencies': ['generate_node_def'],
'msvs_settings': {
'VCLinkerTool': {
'ModuleDefinitionFile': '<(PRODUCT_DIR)/<(node_core_target_name).def',
},
},
}],
],
}],
[ 'node_intermediate_lib_type=="static_library" and node_shared=="false"', {
'xcode_settings': {
'OTHER_LDFLAGS': [
'-Wl,-force_load,<(PRODUCT_DIR)/<(STATIC_LIB_PREFIX)<(node_core_target_name)<(STATIC_LIB_SUFFIX)',
'-Wl,-force_load,<(PRODUCT_DIR)/<(STATIC_LIB_PREFIX)v8_base_without_compiler<(STATIC_LIB_SUFFIX)',
],
},
'msvs_settings': {
'VCLinkerTool': {
'AdditionalOptions': [
'/WHOLEARCHIVE:<(node_lib_target_name)<(STATIC_LIB_SUFFIX)',
'/WHOLEARCHIVE:<(STATIC_LIB_PREFIX)v8_base_without_compiler<(STATIC_LIB_SUFFIX)',
],
},
},
'conditions': [
['OS != "aix" and OS != "mac" and OS != "ios"', {
'ldflags': [
'-Wl,--whole-archive',
'<(obj_dir)/<(STATIC_LIB_PREFIX)<(node_core_target_name)<(STATIC_LIB_SUFFIX)',
'<(obj_dir)/tools/v8_gypfiles/<(STATIC_LIB_PREFIX)v8_base_without_compiler<(STATIC_LIB_SUFFIX)',
'-Wl,--no-whole-archive',
],
}],
[ 'OS=="win"', {
'sources': [ 'src/res/node.rc' ],
}],
],
}],
[ 'node_shared=="true"', {
'xcode_settings': {
build: fix various shared library build issues Node.js unofficially supports a shared library variant where the main node executable is a thin wrapper around node.dll/libnode.so. The key benefit of this is to support embedding Node.js in other applications. Since Node.js 12 there have been a number of issues preventing the shared library build from working correctly, primarily on Windows: * A number of functions used executables such as `mksnapshot` are not exported from `libnode.dll` using a `NODE_EXTERN` attribute * A dependency on the `Winmm` system library is missing * Incorrect defines on executable targets leads to `node.exe` claiming to export a number of functions that are actually in `libnode.dll` * Because `node.exe` attempts to export symbols, `node.lib` gets generated causing native extensions to try to link against `node.exe` not `libnode.dll`. * Similarly, because `node.dll` was renamed to `libnode.dll`, native extensions don't know to look for `libnode.lib` rather than `node.lib`. * On macOS an RPATH is added to find `libnode.dylib` relative to `node` in the same folder. This works fine from the `out/Release` folder but not from an installed prefix, where `node` will be in `bin/` and `libnode.dylib` will be in `lib/`. * Similarly on Linux, no RPATH is added so LD_LIBRARY_PATH needs setting correctly for `bin/node` to find `lib/libnode.so`. For the `libnode.lib` vs `node.lib` issue there are two possible options: 1. Ensure `node.lib` from `node.exe` does not get generated, and instead copy `libnode.lib` to `node.lib`. This means addons compiled when referencing the correct `node.lib` file will correctly depend on `libnode.dll`. The down side is that native addons compiled with stock Node.js will still try to resolve symbols against node.exe rather than libnode.dll. 2. After building `libnode.dll`, dump the exports using `dumpbin`, and process this to generate a `node.def` file to be linked into `node.exe` with the `/DEF:node.def` flag. The export entries in `node.def` will all read ``` my_symbol=libnode.my_symbol ``` so that `node.exe` will redirect all exported symbols back to `libnode.dll`. This has the benefit that addons compiled with stock Node.js will load correctly into `node.exe` from a shared library build, but means that every embedding executable also needs to perform this same trick. I went with the first option as it is the cleaner of the two solutions in my opinion. Projects wishing to generate a shared library variant of Node.js can now, for example, ``` .\vcbuild dll package vs ``` to generate a full node installation including `libnode.dll`, `Release\node.lib`, and all the necessary headers. Native addons can then be built against the shared library build easily by specifying the correct `nodedir` option. For example ``` >npx node-gyp configure --nodedir C:\Users\User\node\Release\node-v18.0.0-win-x64 ... >npx node-gyp build ... >dumpbin /dependents build\Release\binding.node Microsoft (R) COFF/PE Dumper Version 14.29.30136.0 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file build\Release\binding.node File Type: DLL Image has the following dependencies: KERNEL32.dll libnode.dll VCRUNTIME140.dll api-ms-win-crt-string-l1-1-0.dll api-ms-win-crt-stdio-l1-1-0.dll api-ms-win-crt-runtime-l1-1-0.dll ... ``` PR-URL: https://github.com/nodejs/node/pull/41850 Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Beth Griggs <bgriggs@redhat.com> Reviewed-By: Richard Lau <rlau@redhat.com>
2022-02-04 10:12:57 +00:00
'OTHER_LDFLAGS': [ '-Wl,-rpath,@loader_path', '-Wl,-rpath,@loader_path/../lib'],
},
build: fix various shared library build issues Node.js unofficially supports a shared library variant where the main node executable is a thin wrapper around node.dll/libnode.so. The key benefit of this is to support embedding Node.js in other applications. Since Node.js 12 there have been a number of issues preventing the shared library build from working correctly, primarily on Windows: * A number of functions used executables such as `mksnapshot` are not exported from `libnode.dll` using a `NODE_EXTERN` attribute * A dependency on the `Winmm` system library is missing * Incorrect defines on executable targets leads to `node.exe` claiming to export a number of functions that are actually in `libnode.dll` * Because `node.exe` attempts to export symbols, `node.lib` gets generated causing native extensions to try to link against `node.exe` not `libnode.dll`. * Similarly, because `node.dll` was renamed to `libnode.dll`, native extensions don't know to look for `libnode.lib` rather than `node.lib`. * On macOS an RPATH is added to find `libnode.dylib` relative to `node` in the same folder. This works fine from the `out/Release` folder but not from an installed prefix, where `node` will be in `bin/` and `libnode.dylib` will be in `lib/`. * Similarly on Linux, no RPATH is added so LD_LIBRARY_PATH needs setting correctly for `bin/node` to find `lib/libnode.so`. For the `libnode.lib` vs `node.lib` issue there are two possible options: 1. Ensure `node.lib` from `node.exe` does not get generated, and instead copy `libnode.lib` to `node.lib`. This means addons compiled when referencing the correct `node.lib` file will correctly depend on `libnode.dll`. The down side is that native addons compiled with stock Node.js will still try to resolve symbols against node.exe rather than libnode.dll. 2. After building `libnode.dll`, dump the exports using `dumpbin`, and process this to generate a `node.def` file to be linked into `node.exe` with the `/DEF:node.def` flag. The export entries in `node.def` will all read ``` my_symbol=libnode.my_symbol ``` so that `node.exe` will redirect all exported symbols back to `libnode.dll`. This has the benefit that addons compiled with stock Node.js will load correctly into `node.exe` from a shared library build, but means that every embedding executable also needs to perform this same trick. I went with the first option as it is the cleaner of the two solutions in my opinion. Projects wishing to generate a shared library variant of Node.js can now, for example, ``` .\vcbuild dll package vs ``` to generate a full node installation including `libnode.dll`, `Release\node.lib`, and all the necessary headers. Native addons can then be built against the shared library build easily by specifying the correct `nodedir` option. For example ``` >npx node-gyp configure --nodedir C:\Users\User\node\Release\node-v18.0.0-win-x64 ... >npx node-gyp build ... >dumpbin /dependents build\Release\binding.node Microsoft (R) COFF/PE Dumper Version 14.29.30136.0 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file build\Release\binding.node File Type: DLL Image has the following dependencies: KERNEL32.dll libnode.dll VCRUNTIME140.dll api-ms-win-crt-string-l1-1-0.dll api-ms-win-crt-stdio-l1-1-0.dll api-ms-win-crt-runtime-l1-1-0.dll ... ``` PR-URL: https://github.com/nodejs/node/pull/41850 Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Beth Griggs <bgriggs@redhat.com> Reviewed-By: Richard Lau <rlau@redhat.com>
2022-02-04 10:12:57 +00:00
'conditions': [
['OS=="linux"', {
'ldflags': [
'-Wl,-rpath,\\$$ORIGIN/../lib'
],
}],
],
}],
[ 'enable_lto=="true"', {
'xcode_settings': {
'OTHER_LDFLAGS': [
# man ld -export_dynamic:
# Preserves all global symbols in main executables during LTO.
# Without this option, Link Time Optimization is allowed to
# inline and remove global functions. This option is used when
# a main executable may load a plug-in which requires certain
# symbols from the main executable.
'-Wl,-export_dynamic',
],
},
}],
['OS=="win"', {
'libraries': [
'Dbghelp.lib',
'winmm.lib',
'Ws2_32.lib',
src: merge into core Make node-report part of core runtime because: 1. When enabled, node-report significantly helps root cause various types of problems, including support issues sent to the various repos of the Node.js organization. 2. The requirement of explicitly adding the dependency to node-report in user applications often represents a blocker to adoption. Major deviation from the module version of the node-report is that the report is generated in JSON format, as opposed to human readable text. No new functionalities have been added, changes that are required for melding it as a built-in capability has been affected on the module version of node-report (https://github.com/nodejs/node-report) Co-authored-by: Bidisha Pyne <bidipyne@in.ibm.com> Co-authored-by: Howard Hellyer <hhellyer@uk.ibm.com> Co-authored-by: Jeremiah Senkpiel <fishrock123@rocketmail.com> Co-authored-by: Julian Alimin <dmastag@yahoo.com> Co-authored-by: Lakshmi Swetha Gopireddy <lakshmigopireddy@in.ibm.com> Co-authored-by: Manusaporn Treerungroj <m.treerungroj@gmail.com> Co-authored-by: Michael Dawson <michael_dawson@ca.ibm.com> Co-authored-by: Richard Chamberlain <richard_chamberlain@uk.ibm.com> Co-authored-by: Richard Lau <riclau@uk.ibm.com> Co-authored-by: Sam Roberts <vieuxtech@gmail.com> Co-authored-by: Vipin Menon <vipinmv1@in.ibm.com> PR-URL: https://github.com/nodejs/node/pull/22712 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michael Dawson <Michael_Dawson@ca.ibm.com> Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
2018-09-05 10:06:59 -04:00
],
}],
['node_with_ltcg=="true"', {
'msvs_settings': {
'VCCLCompilerTool': {
'WholeProgramOptimization': 'true' # /GL, whole program optimization, needed for LTCG
},
'VCLibrarianTool': {
'AdditionalOptions': [
'/LTCG:INCREMENTAL', # link time code generation
],
},
'VCLinkerTool': {
'OptimizeReferences': 2, # /OPT:REF
'EnableCOMDATFolding': 2, # /OPT:ICF
'LinkIncremental': 1, # disable incremental linking
'AdditionalOptions': [
'/LTCG:INCREMENTAL', # incremental link-time code generation
],
}
}
}, {
'msvs_settings': {
'VCCLCompilerTool': {
'WholeProgramOptimization': 'false'
},
'VCLinkerTool': {
'LinkIncremental': 2 # enable incremental linking
},
},
}],
['node_use_node_snapshot=="true"', {
'dependencies': [
'node_mksnapshot',
],
'conditions': [
['node_snapshot_main!=""', {
'actions': [
{
'action_name': 'node_mksnapshot',
'process_outputs_as_sources': 1,
'inputs': [
'<(node_mksnapshot_exec)',
'<(node_snapshot_main)',
],
'outputs': [
'<(SHARED_INTERMEDIATE_DIR)/node_snapshot.cc',
],
'action': [
'<(node_mksnapshot_exec)',
'--build-snapshot',
'<(node_snapshot_main)',
'<@(_outputs)',
],
},
],
}, {
'actions': [
{
'action_name': 'node_mksnapshot',
'process_outputs_as_sources': 1,
'inputs': [
'<(node_mksnapshot_exec)',
],
'outputs': [
'<(SHARED_INTERMEDIATE_DIR)/node_snapshot.cc',
],
'action': [
'<@(_inputs)',
'<@(_outputs)',
],
},
],
}],
],
}, {
'sources': [
'src/node_snapshot_stub.cc'
],
}],
[ 'OS in "linux freebsd" and '
'target_arch=="x64"', {
'dependencies': [ 'node_text_start' ],
'ldflags+': [
'<(obj_dir)/<(node_text_start_object_path)'
]
}],
['node_fipsinstall=="true"', {
'variables': {
'openssl-cli': '<(PRODUCT_DIR)/<(EXECUTABLE_PREFIX)openssl-cli<(EXECUTABLE_SUFFIX)',
'provider_name': 'libopenssl-fipsmodule',
'opensslconfig': './deps/openssl/nodejs-openssl.cnf',
'conditions': [
['GENERATOR == "ninja"', {
'fipsmodule_internal': '<(PRODUCT_DIR)/lib/<(provider_name).so',
'fipsmodule': '<(PRODUCT_DIR)/obj/lib/openssl-modules/fips.so',
'fipsconfig': '<(PRODUCT_DIR)/obj/lib/fipsmodule.cnf',
'opensslconfig_internal': '<(PRODUCT_DIR)/obj/lib/openssl.cnf',
}, {
'fipsmodule_internal': '<(PRODUCT_DIR)/obj.target/deps/openssl/<(provider_name).so',
'fipsmodule': '<(PRODUCT_DIR)/obj.target/deps/openssl/lib/openssl-modules/fips.so',
'fipsconfig': '<(PRODUCT_DIR)/obj.target/deps/openssl/fipsmodule.cnf',
'opensslconfig_internal': '<(PRODUCT_DIR)/obj.target/deps/openssl/openssl.cnf',
}],
],
},
'actions': [
{
'action_name': 'fipsinstall',
'process_outputs_as_sources': 1,
'inputs': [
'<(fipsmodule_internal)',
],
'outputs': [
'<(fipsconfig)',
],
'action': [
'<(openssl-cli)', 'fipsinstall',
'-provider_name', '<(provider_name)',
'-module', '<(fipsmodule_internal)',
'-out', '<(fipsconfig)',
#'-quiet',
],
},
{
'action_name': 'copy_fips_module',
'inputs': [
'<(fipsmodule_internal)',
],
'outputs': [
'<(fipsmodule)',
],
'action': [
'python', 'tools/copyfile.py',
'<(fipsmodule_internal)',
'<(fipsmodule)',
],
},
{
'action_name': 'copy_openssl_cnf_and_include_fips_cnf',
'inputs': [ '<(opensslconfig)', ],
'outputs': [ '<(opensslconfig_internal)', ],
'action': [
'python', 'tools/enable_fips_include.py',
'<(opensslconfig)',
'<(opensslconfig_internal)',
'<(fipsconfig)',
],
},
],
}, {
'variables': {
'opensslconfig_internal': '<(obj_dir)/deps/openssl/openssl.cnf',
'opensslconfig': './deps/openssl/nodejs-openssl.cnf',
},
'actions': [
{
'action_name': 'reset_openssl_cnf',
'inputs': [ '<(opensslconfig)', ],
'outputs': [ '<(opensslconfig_internal)', ],
'action': [
'<(python)', 'tools/copyfile.py',
'<(opensslconfig)',
'<(opensslconfig_internal)',
],
},
],
}],
],
}, # node_core_target_name
{
'target_name': '<(node_lib_target_name)',
'type': '<(node_intermediate_lib_type)',
'includes': [
'node.gypi',
],
2011-08-04 16:40:07 -07:00
'include_dirs': [
2011-08-08 12:11:48 -07:00
'src',
'<(SHARED_INTERMEDIATE_DIR)' # for node_natives.h
2011-08-04 16:40:07 -07:00
],
'dependencies': [
'deps/base64/base64.gyp:base64',
'deps/googletest/googletest.gyp:gtest_prod',
'deps/histogram/histogram.gyp:histogram',
'deps/uvwasi/uvwasi.gyp:uvwasi',
'deps/simdutf/simdutf.gyp:simdutf',
],
2011-08-04 16:40:07 -07:00
2011-08-03 17:01:30 -07:00
'sources': [
'src/api/async_resource.cc',
'src/api/callback.cc',
'src/api/embed_helpers.cc',
'src/api/encoding.cc',
'src/api/environment.cc',
'src/api/exceptions.cc',
'src/api/hooks.cc',
'src/api/utils.cc',
'src/async_wrap.cc',
'src/base_object.cc',
2011-08-08 12:11:48 -07:00
'src/cares_wrap.cc',
'src/cleanup_queue.cc',
'src/connect_wrap.cc',
'src/connection_wrap.cc',
'src/debug_utils.cc',
'src/env.cc',
'src/fs_event_wrap.cc',
2011-08-08 12:11:48 -07:00
'src/handle_wrap.cc',
'src/heap_utils.cc',
'src/histogram.cc',
src: factor out Node.js-agnostic N-APIs Split the Node.js ECMAScript API (N-EAPI?) into its own header and implementation files. The motivation is that the ECMAScript API stand on its own so it might be embedded separately, implementation and all. Portions of the implementation used by both files are stored in `node_api_impl.h`. The checked boxes below indicate that the given API remains in `node_api.h`, whereas the lack of a checkbox indicates that the API was moved to `node_ecma_api.h`. * [x] NAPI_MODULE * [x] NAPI_MODULE_INIT * [x] napi_acquire_threadsafe_function * [x] napi_add_env_cleanup_hook * [x] napi_async_destroy * [x] napi_async_init * [x] napi_call_threadsafe_function * [x] napi_cancel_async_work * [x] napi_close_callback_scope * [x] napi_create_async_work * [x] napi_create_buffer * [x] napi_create_buffer_copy * [x] napi_create_external_buffer * [x] napi_create_threadsafe_function * [x] napi_delete_async_work * [x] napi_fatal_error * [x] napi_fatal_exception * [x] napi_get_buffer_info * [x] napi_get_node_version * [x] napi_get_threadsafe_function_context * [x] napi_get_uv_event_loop * [x] napi_is_buffer * [x] napi_make_callback * [x] napi_module_register * [x] napi_open_callback_scope * [x] napi_queue_async_work * [x] napi_ref_threadsafe_function * [x] napi_release_threadsafe_function * [x] napi_remove_env_cleanup_hook * [x] napi_unref_threadsafe_function * [ ] napi_add_finalizer * [ ] napi_adjust_external_memory * [ ] napi_call_function * [ ] napi_close_escapable_handle_scope * [ ] napi_close_handle_scope * [ ] napi_coerce_to_bool * [ ] napi_coerce_to_number * [ ] napi_coerce_to_object * [ ] napi_coerce_to_string * [ ] napi_create_array * [ ] napi_create_arraybuffer * [ ] napi_create_array_with_length * [ ] napi_create_bigint_int64 * [ ] napi_create_bigint_uint64 * [ ] napi_create_bigint_words * [ ] napi_create_dataview * [ ] napi_create_double * [ ] napi_create_error * [ ] napi_create_external * [ ] napi_create_external_arraybuffer * [ ] napi_create_function * [ ] napi_create_int32 * [ ] napi_create_int64 * [ ] napi_create_object * [ ] napi_create_promise * [ ] napi_create_range_error * [ ] napi_create_reference * [ ] napi_create_string_latin1 * [ ] napi_create_string_utf16 * [ ] napi_create_string_utf8 * [ ] napi_create_symbol * [ ] napi_create_typedarray * [ ] napi_create_type_error * [ ] napi_create_uint32 * [ ] napi_define_class * [ ] napi_define_properties * [ ] napi_delete_element * [ ] napi_delete_property * [ ] napi_delete_reference * [ ] napi_escape_handle * [ ] napi_get_and_clear_last_exception * [ ] napi_get_arraybuffer_info * [ ] napi_get_array_length * [ ] napi_get_boolean * [ ] napi_get_cb_info * [ ] napi_get_dataview_info * [ ] napi_get_element * [ ] napi_get_global * [ ] napi_get_last_error_info * [ ] napi_get_named_property * [ ] napi_get_new_target * [ ] napi_get_null * [ ] napi_get_property * [ ] napi_get_property_names * [ ] napi_get_prototype * [ ] napi_get_reference_value * [ ] napi_get_typedarray_info * [ ] napi_get_undefined * [ ] napi_get_value_bigint_int64 * [ ] napi_get_value_bigint_uint64 * [ ] napi_get_value_bigint_words * [ ] napi_get_value_bool * [ ] napi_get_value_double * [ ] napi_get_value_external * [ ] napi_get_value_int32 * [ ] napi_get_value_int64 * [ ] napi_get_value_string_latin1 * [ ] napi_get_value_string_utf16 * [ ] napi_get_value_string_utf8 * [ ] napi_get_value_uint32 * [ ] napi_get_version * [ ] napi_has_element * [ ] napi_has_named_property * [ ] napi_has_own_property * [ ] napi_has_property * [ ] napi_instanceof * [ ] napi_is_array * [ ] napi_is_arraybuffer * [ ] napi_is_dataview * [ ] napi_is_error * [ ] napi_is_exception_pending * [ ] napi_is_promise * [ ] napi_is_typedarray * [ ] napi_new_instance * [ ] napi_open_escapable_handle_scope * [ ] napi_open_handle_scope * [ ] napi_reference_ref * [ ] napi_reference_unref * [ ] napi_reject_deferred * [ ] napi_remove_wrap * [ ] napi_resolve_deferred * [ ] napi_run_script * [ ] napi_set_element * [ ] napi_set_named_property * [ ] napi_set_property * [ ] napi_strict_equals * [ ] napi_throw * [ ] napi_throw_error * [ ] napi_throw_range_error * [ ] napi_throw_type_error * [ ] napi_typeof * [ ] napi_unwrap * [ ] napi_wrap PR-URL: https://github.com/nodejs/node/pull/23786 Reviewed-By: Yazhong Liu <yorkiefixer@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
2018-10-19 15:10:59 -04:00
'src/js_native_api.h',
'src/js_native_api_types.h',
'src/js_native_api_v8.cc',
'src/js_native_api_v8.h',
'src/js_native_api_v8_internals.h',
'src/js_stream.cc',
'src/json_utils.cc',
'src/js_udp_wrap.cc',
'src/module_wrap.cc',
2011-08-08 12:11:48 -07:00
'src/node.cc',
n-api: add support for abi stable module API Add support for abi stable module API (N-API) as "Experimental feature". The goal of this API is to provide a stable Node API for native module developers. N-API aims to provide ABI compatibility guarantees across different Node versions and also across different Node VMs - allowing N-API enabled native modules to just work across different versions and flavors of Node.js without recompilation. A more detailed introduction is provided in: https://github.com/nodejs/node-eps/blob/master/005-ABI-Stable-Module-API.md and https://github.com/nodejs/abi-stable-node/blob/doc/VM%20Summit.pdf. The feature, during its experimental state, will be guarded by a runtime flag "--napi-modules". Only when this flag is added to the command line will N-API modules along with regular non N-API modules be supported. The API is defined by the methods in "src/node_api.h" and "src/node_api_types.h". This is the best starting point to review the API surface. More documentation will follow. In addition to the implementation of the API using V8, which is included in this PR, the API has also been validated against chakracore and that port is available in https://github.com/nodejs/abi-stable-node/tree/api-prototype-chakracore-8.x. The current plan is to provide N-API support in versions 8.X and 6.X directly. For older versions, such as 4.X or pre N-API versions of 6.X, we plan to create an external npm module to provide a migration path that will allow modules targeting older Node.js versions to use the API, albeit without getting the advantage of not having to recompile. In addition, we also plan an external npm package with C++ sugar to simplify the use of the API. The sugar will be in-line only and will only use the exported N-API methods but is not part of the N-API itself. The current version is in: https://github.com/nodejs/node-api. This PR is a result of work in the abi-stable-node repo: https://github.com/nodejs/abi-stable-node/tree/doc, with this PR being the cumulative work on the api-prototype-8.x branch with the following contributors in alphabetical order: Author: Arunesh Chandra <arunesh.chandra@microsoft.com> Author: Gabriel Schulhof <gabriel.schulhof@intel.com> Author: Hitesh Kanwathirtha <hiteshk@microsoft.com> Author: Ian Halliday <ianhall@microsoft.com> Author: Jason Ginchereau <jasongin@microsoft.com> Author: Michael Dawson <michael_dawson@ca.ibm.com> Author: Sampson Gao <sampsong@ca.ibm.com> Author: Taylor Woll <taylor.woll@microsoft.com> PR-URL: https://github.com/nodejs/node/pull/11975 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com>
2017-03-20 14:55:26 -07:00
'src/node_api.cc',
'src/node_binding.cc',
'src/node_blob.cc',
2011-08-08 12:11:48 -07:00
'src/node_buffer.cc',
src: disambiguate terms used to refer to builtins and addons The term "native module" dates back to some of the oldest code in the code base. Within the context of Node.js core it usually refers to modules that are native to Node.js (e.g. fs, http), but it can cause confusion for people who don't work on this part of the code base, as "native module" can also refer to native addons - which is even the case in some of the API docs and error messages. This patch tries to make the usage of these terms more consistent. Now within the context of Node.js core: - JavaScript scripts that are built-in to Node.js are now referred to as "built-in(s)". If they are available as modules, they can also be referred to as "built-in module(s)". - Dynamically-linked shared objects that are loaded into the Node.js processes are referred to as "addons". We will try to avoid using the term "native modules" because it could be ambiguous. Changes in this patch: File names: - node_native_module.h -> node_builtins.h, - node_native_module.cc -> node_builtins.cc C++ binding names: - `native_module` -> `builtins` `node::Environment`: - `native_modules_without_cache` -> `builtins_without_cache` - `native_modules_with_cache` -> `builtins_with_cache` - `native_modules_in_snapshot` -> `builtins_in_cache` - `native_module_require` -> `builtin_module_require` `node::EnvSerializeInfo`: - `native_modules` -> `builtins `node::native_module::NativeModuleLoader`: - `native_module` namespace -> `builtins` namespace - `NativeModuleLoader` -> `BuiltinLoader` - `NativeModuleRecordMap` -> `BuiltinSourceMap` - `NativeModuleCacheMap` -> `BuiltinCodeCacheMap` - `ModuleIds` -> `BuiltinIds` - `ModuleCategories` -> `BuiltinCategories` - `LoadBuiltinModuleSource` -> `LoadBuiltinSource` `loader.js`: - `NativeModule` -> `BuiltinModule` (the `NativeModule` name used in `process.moduleLoadList` is kept for compatibility) And other clarifications in the documentation and comments. PR-URL: https://github.com/nodejs/node/pull/44135 Fixes: https://github.com/nodejs/node/issues/44036 Reviewed-By: Jacob Smith <jacob@frende.me> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Jiawen Geng <technicalcute@gmail.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de> Reviewed-By: Jan Krems <jan.krems@gmail.com>
2022-08-05 02:32:06 +08:00
'src/node_builtins.cc',
'src/node_config.cc',
2011-08-08 12:11:48 -07:00
'src/node_constants.cc',
vm, core, module: re-do vm to fix known issues As documented in #3042 and in [1], the existing vm implementation has many problems. All of these are solved by @brianmcd's [contextify][2] package. This commit uses contextify as a conceptual base and its code core to overhaul the vm module and fix its many edge cases and caveats. Functionally, this fixes #3042. In particular: - A context is now indistinguishable from the object it is based on (the "sandbox"). A context is simply a sandbox that has been marked by the vm module, via `vm.createContext`, with special internal information that allows scripts to be run inside of it. - Consequently, items added to the context from anywhere are immediately visible to all code that can access that context, both inside and outside the virtual machine. This commit also smooths over the API very slightly: - Parameter defaults are now uniformly triggered via `undefined`, per ES6 semantics and previous discussion at [3]. - Several undocumented and problematic features have been removed, e.g. the conflation of `vm.Script` with `vm` itself, and the fact that `Script` instances also had all static `vm` methods. The API is now exactly as documented (although arguably the existence of the `vm.Script` export is not yet documented, just the `Script` class itself). In terms of implementation, this replaces node_script.cc with node_contextify.cc, which is derived originally from [4] (see [5]) but has since undergone extensive modifications and iterations to expose the most useful C++ API and use the coding conventions and utilities of Node core. The bindings exposed by `process.binding('contextify')` (node_contextify.cc) replace those formerly exposed by `process.binding('evals')` (node_script.cc). They are: - ContextifyScript(code, [filename]), with methods: - runInThisContext() - runInContext(sandbox, [timeout]) - makeContext(sandbox) From this, the vm.js file builds the entire documented vm module API. node.js and module.js were modified to use this new native binding, or the vm module itself where possible. This introduces an extra line or two into the stack traces of module compilation (and thus into most stack traces), explaining the changed tests. The tests were also updated slightly, with all vm-related simple tests consolidated as test/simple/test-vm-* (some of them were formerly test/simple/test-script-*). At the same time they switched from `common.debug` to `console.error` and were updated to use `assert.throws` instead of rolling their own error-testing methods. New tests were also added, of course, demonstrating the new capabilities and fixes. [1]: http://nodejs.org/docs/v0.10.16/api/vm.html#vm_caveats [2]: https://github.com/brianmcd/contextify [3]: https://github.com/joyent/node/issues/5323#issuecomment-20250726 [4]: https://github.com/kkoopa/contextify/blob/bf123f3ef960f0943d1e30bda02e3163a004e964/src/contextify.cc [5]: https://gist.github.com/domenic/6068120
2013-07-27 00:34:12 -04:00
'src/node_contextify.cc',
'src/node_credentials.cc',
fs: introduce `opendir()` and `fs.Dir` This adds long-requested methods for asynchronously interacting and iterating through directory entries by using `uv_fs_opendir`, `uv_fs_readdir`, and `uv_fs_closedir`. `fs.opendir()` and friends return an `fs.Dir`, which contains methods for doing reads and cleanup. `fs.Dir` also has the async iterator symbol exposed. The `read()` method and friends only return `fs.Dirent`s for this API. Having a entry type or doing a `stat` call is deemed to be necessary in the majority of cases, so just returning dirents seems like the logical choice for a new api. Reading when there are no more entries returns `null` instead of a dirent. However the async iterator hides that (and does automatic cleanup). The code lives in separate files from the rest of fs, this is done partially to prevent over-pollution of those (already very large) files, but also in the case of js allows loading into `fsPromises`. Due to async_hooks, this introduces a new handle type of `DIRHANDLE`. This PR does not attempt to make complete optimization of this feature. Notable future improvements include: - Moving promise work into C++ land like FileHandle. - Possibly adding `readv()` to do multi-entry directory reads. - Aliasing `fs.readdir` to `fs.scandir` and doing a deprecation. Refs: https://github.com/nodejs/node-v0.x-archive/issues/388 Refs: https://github.com/nodejs/node/issues/583 Refs: https://github.com/libuv/libuv/pull/2057 PR-URL: https://github.com/nodejs/node/pull/29349 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: David Carlier <devnexen@gmail.com>
2019-08-27 17:14:27 -07:00
'src/node_dir.cc',
'src/node_env_var.cc',
'src/node_errors.cc',
'src/node_external_reference.cc',
2011-08-08 12:11:48 -07:00
'src/node_file.cc',
'src/node_http_parser.cc',
'src/node_http2.cc',
'src/node_i18n.cc',
'src/node_main_instance.cc',
'src/node_messaging.cc',
'src/node_metadata.cc',
'src/node_options.cc',
2011-08-08 12:11:48 -07:00
'src/node_os.cc',
'src/node_perf.cc',
'src/node_platform.cc',
'src/node_postmortem_metadata.cc',
'src/node_process_events.cc',
'src/node_process_methods.cc',
'src/node_process_object.cc',
'src/node_realm.cc',
'src/node_report.cc',
'src/node_report_module.cc',
'src/node_report_utils.cc',
'src/node_serdes.cc',
'src/node_shadow_realm.cc',
'src/node_snapshotable.cc',
'src/node_sockaddr.cc',
'src/node_stat_watcher.cc',
'src/node_symbols.cc',
'src/node_task_queue.cc',
'src/node_trace_events.cc',
'src/node_types.cc',
'src/node_url.cc',
'src/node_url_tables.cc',
'src/node_util.cc',
'src/node_v8.cc',
'src/node_wasi.cc',
'src/node_wasm_web_api.cc',
'src/node_watchdog.cc',
'src/node_worker.cc',
2011-09-06 16:13:05 -07:00
'src/node_zlib.cc',
2011-08-08 12:11:48 -07:00
'src/pipe_wrap.cc',
'src/process_wrap.cc',
'src/signal_wrap.cc',
'src/spawn_sync.cc',
'src/stream_base.cc',
'src/stream_pipe.cc',
2011-08-08 12:11:48 -07:00
'src/stream_wrap.cc',
'src/string_bytes.cc',
'src/string_decoder.cc',
2011-08-08 12:11:48 -07:00
'src/tcp_wrap.cc',
'src/timers.cc',
'src/timer_wrap.cc',
'src/tracing/agent.cc',
'src/tracing/node_trace_buffer.cc',
'src/tracing/node_trace_writer.cc',
'src/tracing/trace_event.cc',
'src/tracing/traced_value.cc',
2011-09-20 13:38:07 -07:00
'src/tty_wrap.cc',
2011-08-24 16:20:08 -07:00
'src/udp_wrap.cc',
'src/util.cc',
'src/uv.cc',
# headers to make for a more pleasant IDE experience
'src/aliased_buffer.h',
'src/aliased_struct.h',
'src/aliased_struct-inl.h',
'src/async_wrap.h',
'src/async_wrap-inl.h',
'src/base_object.h',
'src/base_object-inl.h',
'src/base64.h',
'src/base64-inl.h',
'src/callback_queue.h',
'src/callback_queue-inl.h',
'src/cleanup_queue.h',
'src/cleanup_queue-inl.h',
'src/connect_wrap.h',
'src/connection_wrap.h',
'src/debug_utils.h',
'src/debug_utils-inl.h',
'src/env_properties.h',
'src/env.h',
'src/env-inl.h',
'src/handle_wrap.h',
'src/histogram.h',
'src/histogram-inl.h',
'src/js_stream.h',
'src/json_utils.h',
'src/large_pages/node_large_page.cc',
'src/large_pages/node_large_page.h',
'src/memory_tracker.h',
'src/memory_tracker-inl.h',
'src/module_wrap.h',
'src/node.h',
'src/node_api.h',
'src/node_api_types.h',
'src/node_binding.h',
'src/node_blob.h',
'src/node_buffer.h',
src: disambiguate terms used to refer to builtins and addons The term "native module" dates back to some of the oldest code in the code base. Within the context of Node.js core it usually refers to modules that are native to Node.js (e.g. fs, http), but it can cause confusion for people who don't work on this part of the code base, as "native module" can also refer to native addons - which is even the case in some of the API docs and error messages. This patch tries to make the usage of these terms more consistent. Now within the context of Node.js core: - JavaScript scripts that are built-in to Node.js are now referred to as "built-in(s)". If they are available as modules, they can also be referred to as "built-in module(s)". - Dynamically-linked shared objects that are loaded into the Node.js processes are referred to as "addons". We will try to avoid using the term "native modules" because it could be ambiguous. Changes in this patch: File names: - node_native_module.h -> node_builtins.h, - node_native_module.cc -> node_builtins.cc C++ binding names: - `native_module` -> `builtins` `node::Environment`: - `native_modules_without_cache` -> `builtins_without_cache` - `native_modules_with_cache` -> `builtins_with_cache` - `native_modules_in_snapshot` -> `builtins_in_cache` - `native_module_require` -> `builtin_module_require` `node::EnvSerializeInfo`: - `native_modules` -> `builtins `node::native_module::NativeModuleLoader`: - `native_module` namespace -> `builtins` namespace - `NativeModuleLoader` -> `BuiltinLoader` - `NativeModuleRecordMap` -> `BuiltinSourceMap` - `NativeModuleCacheMap` -> `BuiltinCodeCacheMap` - `ModuleIds` -> `BuiltinIds` - `ModuleCategories` -> `BuiltinCategories` - `LoadBuiltinModuleSource` -> `LoadBuiltinSource` `loader.js`: - `NativeModule` -> `BuiltinModule` (the `NativeModule` name used in `process.moduleLoadList` is kept for compatibility) And other clarifications in the documentation and comments. PR-URL: https://github.com/nodejs/node/pull/44135 Fixes: https://github.com/nodejs/node/issues/44036 Reviewed-By: Jacob Smith <jacob@frende.me> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Jiawen Geng <technicalcute@gmail.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de> Reviewed-By: Jan Krems <jan.krems@gmail.com>
2022-08-05 02:32:06 +08:00
'src/node_builtins.h',
'src/node_constants.h',
'src/node_context_data.h',
'src/node_contextify.h',
fs: introduce `opendir()` and `fs.Dir` This adds long-requested methods for asynchronously interacting and iterating through directory entries by using `uv_fs_opendir`, `uv_fs_readdir`, and `uv_fs_closedir`. `fs.opendir()` and friends return an `fs.Dir`, which contains methods for doing reads and cleanup. `fs.Dir` also has the async iterator symbol exposed. The `read()` method and friends only return `fs.Dirent`s for this API. Having a entry type or doing a `stat` call is deemed to be necessary in the majority of cases, so just returning dirents seems like the logical choice for a new api. Reading when there are no more entries returns `null` instead of a dirent. However the async iterator hides that (and does automatic cleanup). The code lives in separate files from the rest of fs, this is done partially to prevent over-pollution of those (already very large) files, but also in the case of js allows loading into `fsPromises`. Due to async_hooks, this introduces a new handle type of `DIRHANDLE`. This PR does not attempt to make complete optimization of this feature. Notable future improvements include: - Moving promise work into C++ land like FileHandle. - Possibly adding `readv()` to do multi-entry directory reads. - Aliasing `fs.readdir` to `fs.scandir` and doing a deprecation. Refs: https://github.com/nodejs/node-v0.x-archive/issues/388 Refs: https://github.com/nodejs/node/issues/583 Refs: https://github.com/libuv/libuv/pull/2057 PR-URL: https://github.com/nodejs/node/pull/29349 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: David Carlier <devnexen@gmail.com>
2019-08-27 17:14:27 -07:00
'src/node_dir.h',
'src/node_errors.h',
'src/node_exit_code.h',
'src/node_external_reference.h',
'src/node_file.h',
'src/node_file-inl.h',
'src/node_http_common.h',
'src/node_http_common-inl.h',
http2: introducing HTTP/2 At long last: The initial *experimental* implementation of HTTP/2. This is an accumulation of the work that has been done in the nodejs/http2 repository, squashed down to a couple of commits. The original commit history has been preserved in the nodejs/http2 repository. This PR introduces the nghttp2 C library as a new dependency. This library provides the majority of the HTTP/2 protocol implementation, with the rest of the code here providing the mapping of the library into a usable JS API. Within src, a handful of new node_http2_*.c and node_http2_*.h files are introduced. These provide the internal mechanisms that interface with nghttp and define the `process.binding('http2')` interface. The JS API is defined within `internal/http2/*.js`. There are two APIs provided: Core and Compat. The Core API is HTTP/2 specific and is designed to be as minimal and as efficient as possible. The Compat API is intended to be as close to the existing HTTP/1 API as possible, with some exceptions. Tests, documentation and initial benchmarks are included. The `http2` module is gated by a new `--expose-http2` command line flag. When used, `require('http2')` will be exposed to users. Note that there is an existing `http2` module on npm that would be impacted by the introduction of this module, which is the main reason for gating this behind a flag. When using `require('http2')` the first time, a process warning will be emitted indicating that an experimental feature is being used. To run the benchmarks, the `h2load` tool (part of the nghttp project) is required: `./node benchmarks/http2/simple.js benchmarker=h2load`. Only two benchmarks are currently available. Additional configuration options to enable verbose debugging are provided: ``` $ ./configure --debug-http2 --debug-nghttp2 $ NODE_DEBUG=http2 ./node ``` The `--debug-http2` configuration option enables verbose debug statements from the `src/node_http2_*` files. The `--debug-nghttp2` enables the nghttp library's own verbose debug output. The `NODE_DEBUG=http2` enables JS-level debug output. The following illustrates as simple HTTP/2 server and client interaction: (The HTTP/2 client and server support both plain text and TLS connections) ```jt client = http2.connect('http://localhost:80'); const req = client.request({ ':path': '/some/path' }); req.on('data', (chunk) => { /* do something with the data */ }); req.on('end', () => { client.destroy(); }); // Plain text (non-TLS server) const server = http2.createServer(); server.on('stream', (stream, requestHeaders) => { stream.respond({ ':status': 200 }); stream.write('hello '); stream.end('world'); }); server.listen(80); ``` ```js const http2 = require('http2'); const client = http2.connect('http://localhost'); ``` Author: Anna Henningsen <anna@addaleax.net> Author: Colin Ihrig <cjihrig@gmail.com> Author: Daniel Bevenius <daniel.bevenius@gmail.com> Author: James M Snell <jasnell@gmail.com> Author: Jun Mukai Author: Kelvin Jin Author: Matteo Collina <matteo.collina@gmail.com> Author: Robert Kowalski <rok@kowalski.gd> Author: Santiago Gimeno <santiago.gimeno@gmail.com> Author: Sebastiaan Deckers <sebdeckers83@gmail.com> Author: Yosuke Furukawa <yosuke.furukawa@gmail.com> PR-URL: https://github.com/nodejs/node/pull/14239 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
2017-07-17 10:17:16 -07:00
'src/node_http2.h',
'src/node_http2_state.h',
'src/node_i18n.h',
'src/node_internals.h',
'src/node_main_instance.h',
'src/node_mem.h',
'src/node_mem-inl.h',
'src/node_messaging.h',
'src/node_metadata.h',
'src/node_mutex.h',
'src/node_object_wrap.h',
'src/node_options.h',
'src/node_options-inl.h',
'src/node_perf.h',
'src/node_perf_common.h',
'src/node_platform.h',
'src/node_process.h',
'src/node_process-inl.h',
'src/node_realm.h',
'src/node_realm-inl.h',
'src/node_report.h',
'src/node_revert.h',
'src/node_root_certs.h',
'src/node_shadow_realm.h',
'src/node_snapshotable.h',
'src/node_snapshot_builder.h',
'src/node_sockaddr.h',
'src/node_sockaddr-inl.h',
'src/node_stat_watcher.h',
src: use STL containers instead of v8 values for static module data Instead of putting the source code and the cache in v8::Objects, put them in per-process std::maps. This has the following benefits: - It's slightly lighter in weight compared to storing things on the v8 heap. Also it may be slightly faster since the preivous v8::Object is already in dictionary mode - though the difference is very small given the number of native modules is limited. - The source and code cache generation templates are now much simpler since they just initialize static arrays and manipulate STL constructs. - The static native module data can be accessed independently of any Environment or Isolate, and it's easy to look them up from the C++'s side. - It's now impossible to mutate the source code used to compile native modules from the JS land since it's completely separate from the v8 heap. We can still get the constant strings from process.binding('natives') but that's all. A few drive-by fixes: - Remove DecorateErrorStack in LookupAndCompile - We don't need to capture the exception to decorate when we encounter errors during native module compilation, as those errors should be syntax errors and v8 is able to decorate them well. We use CompileFunctionInContext so there is no need to worry about wrappers either. - The code cache could be rejected when node is started with v8 flags. Instead of aborting in that case, simply keep a record in the native_module_without_cache set. - Refactor js2c.py a bit, reduce code duplication and inline Render() to make the one-byte/two-byte special treatment easier to read. PR-URL: https://github.com/nodejs/node/pull/24384 Fixes: https://github.com/Remove Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com> Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
2018-11-14 22:38:12 +08:00
'src/node_union_bytes.h',
'src/node_url.h',
'src/node_util.h',
'src/node_version.h',
'src/node_v8.h',
'src/node_v8_platform-inl.h',
'src/node_wasi.h',
'src/node_watchdog.h',
'src/node_worker.h',
'src/pipe_wrap.h',
'src/req_wrap.h',
'src/req_wrap-inl.h',
'src/spawn_sync.h',
'src/stream_base.h',
'src/stream_base-inl.h',
'src/stream_pipe.h',
'src/stream_wrap.h',
'src/string_bytes.h',
'src/string_decoder.h',
'src/string_decoder-inl.h',
'src/string_search.h',
'src/tcp_wrap.h',
'src/tracing/agent.h',
'src/tracing/node_trace_buffer.h',
'src/tracing/node_trace_writer.h',
'src/tracing/trace_event.h',
'src/tracing/trace_event_common.h',
'src/tracing/traced_value.h',
'src/timer_wrap.h',
'src/timer_wrap-inl.h',
'src/tty_wrap.h',
'src/udp_wrap.h',
'src/util.h',
'src/util-inl.h',
# Dependency headers
'deps/v8/include/v8.h',
2011-09-05 01:01:53 +02:00
# javascript files to make for an even more pleasant IDE experience
'<@(library_files)',
'<@(deps_files)',
# node.gyp is added by default, common.gypi is added for change detection
2011-10-28 12:10:24 +02:00
'common.gypi',
2011-08-04 16:40:07 -07:00
],
'variables': {
'openssl_system_ca_path%': '',
'openssl_default_cipher_list%': '',
},
'cflags': ['-Werror=unused-result'],
2011-08-04 16:40:07 -07:00
'defines': [
'NODE_ARCH="<(target_arch)"',
'NODE_PLATFORM="<(OS)"',
'NODE_WANT_INTERNALS=1',
# Warn when using deprecated V8 APIs.
'V8_DEPRECATION_WARNINGS=1',
'NODE_OPENSSL_SYSTEM_CERT_PATH="<(openssl_system_ca_path)"',
2011-08-03 17:01:30 -07:00
],
# - "C4244: conversion from 'type1' to 'type2', possible loss of data"
# Ususaly safe. Disable for `dep`, enable for `src`
'msvs_disabled_warnings!': [4244],
'conditions': [
[ 'openssl_default_cipher_list!=""', {
'defines': [
'NODE_OPENSSL_DEFAULT_CIPHER_LIST="<(openssl_default_cipher_list)"'
]
}],
[ 'error_on_warn=="true"', {
'cflags': ['-Werror'],
'xcode_settings': {
'WARNING_CFLAGS': [ '-Werror' ],
},
}],
[ 'node_builtin_modules_path!=""', {
'defines': [ 'NODE_BUILTIN_MODULES_PATH="<(node_builtin_modules_path)"' ]
}],
[ 'node_shared=="true"', {
'sources': [
'src/node_snapshot_stub.cc',
]
}],
[ 'node_shared=="true" and node_module_version!="" and OS!="win"', {
'product_extension': '<(shlib_suffix)',
'xcode_settings': {
'LD_DYLIB_INSTALL_NAME':
'@rpath/lib<(node_core_target_name).<(shlib_suffix)'
},
}],
[ 'node_use_node_code_cache=="true"', {
'defines': [
'NODE_USE_NODE_CODE_CACHE=1',
],
}],
['node_shared=="true" and OS=="aix"', {
'product_name': 'node_base',
}],
[ 'v8_enable_inspector==1', {
'includes' : [ 'src/inspector/node_inspector.gypi' ],
}, {
'defines': [ 'HAVE_INSPECTOR=0' ]
}],
[ 'OS=="win"', {
'conditions': [
[ 'node_intermediate_lib_type!="static_library"', {
'sources': [
'src/res/node.rc',
],
}],
],
'libraries': [
'Dbghelp',
'Psapi',
build: fix various shared library build issues Node.js unofficially supports a shared library variant where the main node executable is a thin wrapper around node.dll/libnode.so. The key benefit of this is to support embedding Node.js in other applications. Since Node.js 12 there have been a number of issues preventing the shared library build from working correctly, primarily on Windows: * A number of functions used executables such as `mksnapshot` are not exported from `libnode.dll` using a `NODE_EXTERN` attribute * A dependency on the `Winmm` system library is missing * Incorrect defines on executable targets leads to `node.exe` claiming to export a number of functions that are actually in `libnode.dll` * Because `node.exe` attempts to export symbols, `node.lib` gets generated causing native extensions to try to link against `node.exe` not `libnode.dll`. * Similarly, because `node.dll` was renamed to `libnode.dll`, native extensions don't know to look for `libnode.lib` rather than `node.lib`. * On macOS an RPATH is added to find `libnode.dylib` relative to `node` in the same folder. This works fine from the `out/Release` folder but not from an installed prefix, where `node` will be in `bin/` and `libnode.dylib` will be in `lib/`. * Similarly on Linux, no RPATH is added so LD_LIBRARY_PATH needs setting correctly for `bin/node` to find `lib/libnode.so`. For the `libnode.lib` vs `node.lib` issue there are two possible options: 1. Ensure `node.lib` from `node.exe` does not get generated, and instead copy `libnode.lib` to `node.lib`. This means addons compiled when referencing the correct `node.lib` file will correctly depend on `libnode.dll`. The down side is that native addons compiled with stock Node.js will still try to resolve symbols against node.exe rather than libnode.dll. 2. After building `libnode.dll`, dump the exports using `dumpbin`, and process this to generate a `node.def` file to be linked into `node.exe` with the `/DEF:node.def` flag. The export entries in `node.def` will all read ``` my_symbol=libnode.my_symbol ``` so that `node.exe` will redirect all exported symbols back to `libnode.dll`. This has the benefit that addons compiled with stock Node.js will load correctly into `node.exe` from a shared library build, but means that every embedding executable also needs to perform this same trick. I went with the first option as it is the cleaner of the two solutions in my opinion. Projects wishing to generate a shared library variant of Node.js can now, for example, ``` .\vcbuild dll package vs ``` to generate a full node installation including `libnode.dll`, `Release\node.lib`, and all the necessary headers. Native addons can then be built against the shared library build easily by specifying the correct `nodedir` option. For example ``` >npx node-gyp configure --nodedir C:\Users\User\node\Release\node-v18.0.0-win-x64 ... >npx node-gyp build ... >dumpbin /dependents build\Release\binding.node Microsoft (R) COFF/PE Dumper Version 14.29.30136.0 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file build\Release\binding.node File Type: DLL Image has the following dependencies: KERNEL32.dll libnode.dll VCRUNTIME140.dll api-ms-win-crt-string-l1-1-0.dll api-ms-win-crt-stdio-l1-1-0.dll api-ms-win-crt-runtime-l1-1-0.dll ... ``` PR-URL: https://github.com/nodejs/node/pull/41850 Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Beth Griggs <bgriggs@redhat.com> Reviewed-By: Richard Lau <rlau@redhat.com>
2022-02-04 10:12:57 +00:00
'Winmm',
'Ws2_32',
],
}],
[ 'node_use_openssl=="true"', {
'sources': [
'src/crypto/crypto_aes.cc',
'src/crypto/crypto_bio.cc',
'src/crypto/crypto_common.cc',
'src/crypto/crypto_dsa.cc',
'src/crypto/crypto_hkdf.cc',
'src/crypto/crypto_pbkdf2.cc',
'src/crypto/crypto_sig.cc',
'src/crypto/crypto_timing.cc',
'src/crypto/crypto_cipher.cc',
'src/crypto/crypto_context.cc',
'src/crypto/crypto_ec.cc',
'src/crypto/crypto_hmac.cc',
'src/crypto/crypto_random.cc',
'src/crypto/crypto_rsa.cc',
'src/crypto/crypto_spkac.cc',
'src/crypto/crypto_util.cc',
'src/crypto/crypto_clienthello.cc',
'src/crypto/crypto_dh.cc',
'src/crypto/crypto_hash.cc',
'src/crypto/crypto_keys.cc',
'src/crypto/crypto_keygen.cc',
'src/crypto/crypto_scrypt.cc',
'src/crypto/crypto_tls.cc',
'src/crypto/crypto_aes.cc',
'src/crypto/crypto_x509.cc',
'src/crypto/crypto_bio.h',
'src/crypto/crypto_clienthello-inl.h',
'src/crypto/crypto_dh.h',
'src/crypto/crypto_hmac.h',
'src/crypto/crypto_rsa.h',
'src/crypto/crypto_spkac.h',
'src/crypto/crypto_util.h',
'src/crypto/crypto_cipher.h',
'src/crypto/crypto_common.h',
'src/crypto/crypto_dsa.h',
'src/crypto/crypto_hash.h',
'src/crypto/crypto_keys.h',
'src/crypto/crypto_keygen.h',
'src/crypto/crypto_scrypt.h',
'src/crypto/crypto_tls.h',
'src/crypto/crypto_clienthello.h',
'src/crypto/crypto_context.h',
'src/crypto/crypto_ec.h',
'src/crypto/crypto_hkdf.h',
'src/crypto/crypto_pbkdf2.h',
'src/crypto/crypto_sig.h',
'src/crypto/crypto_random.h',
'src/crypto/crypto_timing.h',
'src/crypto/crypto_x509.h',
'src/node_crypto.cc',
'src/node_crypto.h'
],
}],
[ 'OS in "linux freebsd mac solaris" and '
'target_arch=="x64" and '
'node_target_type=="executable"', {
'defines': [ 'NODE_ENABLE_LARGE_CODE_PAGES=1' ],
}],
[ 'use_openssl_def==1', {
# TODO(bnoordhuis) Make all platforms export the same list of symbols.
# Teach mkssldef.py to generate linker maps that UNIX linkers understand.
'variables': {
'mkssldef_flags': [
# Categories to export.
'-CAES,BF,BIO,DES,DH,DSA,EC,ECDH,ECDSA,ENGINE,EVP,HMAC,MD4,MD5,'
'PSK,RC2,RC4,RSA,SHA,SHA0,SHA1,SHA256,SHA512,SOCK,STDIO,TLSEXT,'
'UI,FP_API,TLS1_METHOD,TLS1_1_METHOD,TLS1_2_METHOD,SCRYPT,OCSP,'
'NEXTPROTONEG,RMD160,CAST,DEPRECATEDIN_1_1_0,DEPRECATEDIN_1_2_0',
# Defines.
'-DWIN32',
# Symbols to filter from the export list.
'-X^DSO',
'-X^_',
'-X^private_',
# Base generated DEF on zlib.def
'-Bdeps/zlib/win32/zlib.def'
],
},
'conditions': [
['openssl_is_fips!=""', {
'variables': { 'mkssldef_flags': ['-DOPENSSL_FIPS'] },
}],
],
'actions': [
{
'action_name': 'mkssldef',
'inputs': [
'deps/openssl/openssl/util/libcrypto.num',
'deps/openssl/openssl/util/libssl.num',
],
'outputs': ['<(SHARED_INTERMEDIATE_DIR)/openssl.def'],
'process_outputs_as_sources': 1,
'action': [
'<(python)',
'tools/mkssldef.py',
'<@(mkssldef_flags)',
'-o',
'<@(_outputs)',
'<@(_inputs)',
],
},
],
}],
[ 'debug_nghttp2==1', {
'defines': [ 'NODE_DEBUG_NGHTTP2=1' ]
}],
],
2011-08-03 17:01:30 -07:00
'actions': [
{
'action_name': 'node_js2c',
'process_outputs_as_sources': 1,
2011-08-03 17:01:30 -07:00
'inputs': [
# Put the code first so it's a dependency and can be used for invocation.
'tools/js2c.py',
2011-08-03 17:01:30 -07:00
'<@(library_files)',
'<@(deps_files)',
'config.gypi'
2011-08-03 17:01:30 -07:00
],
'outputs': [
'<(SHARED_INTERMEDIATE_DIR)/node_javascript.cc',
2011-08-03 17:01:30 -07:00
],
'action': [
'<(python)',
'tools/js2c.py',
'--directory',
'lib',
'--target',
'<@(_outputs)',
'config.gypi',
'<@(deps_files)',
],
2011-08-03 17:01:30 -07:00
},
],
}, # node_lib_target_name
{ # fuzz_url
'target_name': 'fuzz_url',
'type': 'executable',
'dependencies': [
'<(node_lib_target_name)',
],
'includes': [
'node.gypi'
],
'include_dirs': [
'src',
],
'defines': [
'NODE_ARCH="<(target_arch)"',
'NODE_PLATFORM="<(OS)"',
'NODE_WANT_INTERNALS=1',
],
'sources': [
'src/node_snapshot_stub.cc',
'test/fuzzers/fuzz_url.cc',
],
'conditions': [
['OS=="linux"', {
'ldflags': [ '-fsanitize=fuzzer' ]
}],
# Ensure that ossfuzz flag has been set and that we are on Linux
[ 'OS!="linux" or ossfuzz!="true"', {
'type': 'none',
}],
],
}, # fuzz_url
{ # fuzz_env
'target_name': 'fuzz_env',
'type': 'executable',
'dependencies': [
'<(node_lib_target_name)',
'deps/histogram/histogram.gyp:histogram',
'deps/uvwasi/uvwasi.gyp:uvwasi',
],
'includes': [
'node.gypi'
],
'include_dirs': [
'src',
'tools/msvs/genfiles',
'deps/v8/include',
'deps/cares/include',
'deps/uv/include',
'deps/uvwasi/include',
'test/cctest',
],
'defines': [
'NODE_ARCH="<(target_arch)"',
'NODE_PLATFORM="<(OS)"',
'NODE_WANT_INTERNALS=1',
],
'sources': [
'src/node_snapshot_stub.cc',
'test/fuzzers/fuzz_env.cc',
],
'conditions': [
['OS=="linux"', {
'ldflags': [ '-fsanitize=fuzzer' ]
}],
# Ensure that ossfuzz flag has been set and that we are on Linux
[ 'OS!="linux" or ossfuzz!="true"', {
'type': 'none',
}],
],
}, # fuzz_env
{
'target_name': 'cctest',
'type': 'executable',
'dependencies': [
'<(node_lib_target_name)',
'deps/base64/base64.gyp:base64',
'deps/googletest/googletest.gyp:gtest',
'deps/googletest/googletest.gyp:gtest_main',
'deps/histogram/histogram.gyp:histogram',
'deps/uvwasi/uvwasi.gyp:uvwasi',
'deps/simdutf/simdutf.gyp:simdutf',
],
'includes': [
'node.gypi'
],
'include_dirs': [
'src',
'tools/msvs/genfiles',
'deps/v8/include',
'deps/cares/include',
'deps/uv/include',
'deps/uvwasi/include',
'test/cctest',
],
'defines': [
'NODE_ARCH="<(target_arch)"',
'NODE_PLATFORM="<(OS)"',
'NODE_WANT_INTERNALS=1',
],
'sources': [
'src/node_snapshot_stub.cc',
'test/cctest/node_test_fixture.cc',
'test/cctest/node_test_fixture.h',
'test/cctest/test_aliased_buffer.cc',
'test/cctest/test_base64.cc',
'test/cctest/test_base_object_ptr.cc',
'test/cctest/test_node_postmortem_metadata.cc',
'test/cctest/test_environment.cc',
'test/cctest/test_linked_binding.cc',
'test/cctest/test_node_api.cc',
'test/cctest/test_per_process.cc',
'test/cctest/test_platform.cc',
'test/cctest/test_report.cc',
'test/cctest/test_json_utils.cc',
'test/cctest/test_sockaddr.cc',
'test/cctest/test_traced_value.cc',
'test/cctest/test_util.cc',
'test/cctest/test_url.cc',
],
'conditions': [
[ 'node_use_openssl=="true"', {
'defines': [
'HAVE_OPENSSL=1',
],
'sources': [
'test/cctest/test_crypto_clienthello.cc',
'test/cctest/test_node_crypto.cc',
]
}],
['v8_enable_inspector==1', {
'sources': [
'test/cctest/test_inspector_socket.cc',
'test/cctest/test_inspector_socket_server.cc'
],
'defines': [
'HAVE_INSPECTOR=1',
],
}, {
'defines': [
'HAVE_INSPECTOR=0',
]
}],
['OS=="solaris"', {
'ldflags': [ '-I<(SHARED_INTERMEDIATE_DIR)' ]
}],
# Skip cctest while building shared lib node for Windows
[ 'OS=="win" and node_shared=="true"', {
'type': 'none',
}],
[ 'node_shared=="true"', {
'xcode_settings': {
'OTHER_LDFLAGS': [ '-Wl,-rpath,@loader_path', ],
},
}],
['OS=="win"', {
'libraries': [
'Dbghelp.lib',
'winmm.lib',
'Ws2_32.lib',
],
}],
],
}, # cctest
{
'target_name': 'embedtest',
'type': 'executable',
'dependencies': [
'<(node_lib_target_name)',
'deps/histogram/histogram.gyp:histogram',
'deps/uvwasi/uvwasi.gyp:uvwasi',
],
'includes': [
'node.gypi'
],
'include_dirs': [
'src',
'tools/msvs/genfiles',
'deps/v8/include',
'deps/cares/include',
'deps/uv/include',
'deps/uvwasi/include',
'test/embedding',
],
'sources': [
'src/node_snapshot_stub.cc',
'test/embedding/embedtest.cc',
],
'conditions': [
['OS=="solaris"', {
'ldflags': [ '-I<(SHARED_INTERMEDIATE_DIR)' ]
}],
# Skip cctest while building shared lib node for Windows
[ 'OS=="win" and node_shared=="true"', {
'type': 'none',
}],
[ 'node_shared=="true"', {
'xcode_settings': {
'OTHER_LDFLAGS': [ '-Wl,-rpath,@loader_path', ],
},
}],
['OS=="win"', {
'libraries': [
'Dbghelp.lib',
'winmm.lib',
'Ws2_32.lib',
],
}],
],
}, # embedtest
{
'target_name': 'overlapped-checker',
'type': 'executable',
'conditions': [
['OS=="win"', {
'sources': [
'test/overlapped-checker/main_win.c'
],
}],
['OS!="win"', {
'sources': [
'test/overlapped-checker/main_unix.c'
],
}],
]
}, # overlapped-checker
{
'target_name': 'node_mksnapshot',
'type': 'executable',
'dependencies': [
'<(node_lib_target_name)',
'deps/histogram/histogram.gyp:histogram',
'deps/uvwasi/uvwasi.gyp:uvwasi',
],
'includes': [
'node.gypi'
],
'include_dirs': [
'src',
'tools/msvs/genfiles',
'deps/v8/include',
'deps/cares/include',
'deps/uv/include',
'deps/uvwasi/include',
],
'defines': [ 'NODE_WANT_INTERNALS=1' ],
'sources': [
'src/node_snapshot_stub.cc',
'tools/snapshot/node_mksnapshot.cc',
],
'conditions': [
[ 'node_use_openssl=="true"', {
'defines': [
'HAVE_OPENSSL=1',
],
}],
[ 'node_use_node_code_cache=="true"', {
'defines': [
'NODE_USE_NODE_CODE_CACHE=1',
],
}],
['v8_enable_inspector==1', {
'defines': [
'HAVE_INSPECTOR=1',
],
}],
['OS=="win"', {
'libraries': [
'Dbghelp.lib',
'winmm.lib',
'Ws2_32.lib',
],
}],
],
}, # node_mksnapshot
], # end targets
build: Updates for AIX npm support - part 1 This PR is the first step enabling support for native modules for AIX. The main issue is that unlike linux where all symbols within the Node executable are available to the shared library for a native module (npm), on AIX the symbols must be explicitly exported. In addition, when the shared library is built it must be linked using a list of the available symbols. This patch covers the changes need to: 1) Export the symbols when building the node executable 2) Generate the file listing the symbols that can be used when building the shared library. For AIX, it breaks the build process into 2 steps. The first builds a static library and then generates a node.exp file which contains the symbols from that library. The second builds the node executable and uses the node.exp file to specify which symbols should be exported. In addition, it save the node.exp file so that it can later be used in the creation of the shared library when building a native module. The following additional steps will be required in dependent projects to fully enable AIX for native modules and are being worked separately: - Updates to node-gyp to use node.exp when creating the shared library for a native module - Fixes to gyp related to copying files as covered in https://codereview.chromium.org/1368133002/patch/1/10001 - Pulling in updated gyp versions to Node and node-gyp - Pulling latest libuv These changes were done to minimize the change to other platforms by working within the existing structure to add the 2 step process for AIX without changing the process for other platforms. PR-URL: https://github.com/nodejs/node/pull/3114 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
2015-09-29 10:22:00 -04:00
'conditions': [
['OS=="aix" and node_shared=="true"', {
'targets': [
{
'target_name': 'node_aix_shared',
'type': 'shared_library',
'product_name': '<(node_core_target_name)',
'ldflags': ['--shared'],
'product_extension': '<(shlib_suffix)',
'includes': [
'node.gypi'
],
'dependencies': ['<(node_lib_target_name)'],
build: Updates for AIX npm support - part 1 This PR is the first step enabling support for native modules for AIX. The main issue is that unlike linux where all symbols within the Node executable are available to the shared library for a native module (npm), on AIX the symbols must be explicitly exported. In addition, when the shared library is built it must be linked using a list of the available symbols. This patch covers the changes need to: 1) Export the symbols when building the node executable 2) Generate the file listing the symbols that can be used when building the shared library. For AIX, it breaks the build process into 2 steps. The first builds a static library and then generates a node.exp file which contains the symbols from that library. The second builds the node executable and uses the node.exp file to specify which symbols should be exported. In addition, it save the node.exp file so that it can later be used in the creation of the shared library when building a native module. The following additional steps will be required in dependent projects to fully enable AIX for native modules and are being worked separately: - Updates to node-gyp to use node.exp when creating the shared library for a native module - Fixes to gyp related to copying files as covered in https://codereview.chromium.org/1368133002/patch/1/10001 - Pulling in updated gyp versions to Node and node-gyp - Pulling latest libuv These changes were done to minimize the change to other platforms by working within the existing structure to add the 2 step process for AIX without changing the process for other platforms. PR-URL: https://github.com/nodejs/node/pull/3114 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
2015-09-29 10:22:00 -04:00
'include_dirs': [
'src',
'deps/v8/include',
],
'sources': [
'<@(library_files)',
'<@(deps_files)',
build: Updates for AIX npm support - part 1 This PR is the first step enabling support for native modules for AIX. The main issue is that unlike linux where all symbols within the Node executable are available to the shared library for a native module (npm), on AIX the symbols must be explicitly exported. In addition, when the shared library is built it must be linked using a list of the available symbols. This patch covers the changes need to: 1) Export the symbols when building the node executable 2) Generate the file listing the symbols that can be used when building the shared library. For AIX, it breaks the build process into 2 steps. The first builds a static library and then generates a node.exp file which contains the symbols from that library. The second builds the node executable and uses the node.exp file to specify which symbols should be exported. In addition, it save the node.exp file so that it can later be used in the creation of the shared library when building a native module. The following additional steps will be required in dependent projects to fully enable AIX for native modules and are being worked separately: - Updates to node-gyp to use node.exp when creating the shared library for a native module - Fixes to gyp related to copying files as covered in https://codereview.chromium.org/1368133002/patch/1/10001 - Pulling in updated gyp versions to Node and node-gyp - Pulling latest libuv These changes were done to minimize the change to other platforms by working within the existing structure to add the 2 step process for AIX without changing the process for other platforms. PR-URL: https://github.com/nodejs/node/pull/3114 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
2015-09-29 10:22:00 -04:00
'common.gypi',
],
'direct_dependent_settings': {
'ldflags': [ '-Wl,-brtl' ],
},
build: Updates for AIX npm support - part 1 This PR is the first step enabling support for native modules for AIX. The main issue is that unlike linux where all symbols within the Node executable are available to the shared library for a native module (npm), on AIX the symbols must be explicitly exported. In addition, when the shared library is built it must be linked using a list of the available symbols. This patch covers the changes need to: 1) Export the symbols when building the node executable 2) Generate the file listing the symbols that can be used when building the shared library. For AIX, it breaks the build process into 2 steps. The first builds a static library and then generates a node.exp file which contains the symbols from that library. The second builds the node executable and uses the node.exp file to specify which symbols should be exported. In addition, it save the node.exp file so that it can later be used in the creation of the shared library when building a native module. The following additional steps will be required in dependent projects to fully enable AIX for native modules and are being worked separately: - Updates to node-gyp to use node.exp when creating the shared library for a native module - Fixes to gyp related to copying files as covered in https://codereview.chromium.org/1368133002/patch/1/10001 - Pulling in updated gyp versions to Node and node-gyp - Pulling latest libuv These changes were done to minimize the change to other platforms by working within the existing structure to add the 2 step process for AIX without changing the process for other platforms. PR-URL: https://github.com/nodejs/node/pull/3114 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
2015-09-29 10:22:00 -04:00
},
]
build: Updates for AIX npm support - part 1 This PR is the first step enabling support for native modules for AIX. The main issue is that unlike linux where all symbols within the Node executable are available to the shared library for a native module (npm), on AIX the symbols must be explicitly exported. In addition, when the shared library is built it must be linked using a list of the available symbols. This patch covers the changes need to: 1) Export the symbols when building the node executable 2) Generate the file listing the symbols that can be used when building the shared library. For AIX, it breaks the build process into 2 steps. The first builds a static library and then generates a node.exp file which contains the symbols from that library. The second builds the node executable and uses the node.exp file to specify which symbols should be exported. In addition, it save the node.exp file so that it can later be used in the creation of the shared library when building a native module. The following additional steps will be required in dependent projects to fully enable AIX for native modules and are being worked separately: - Updates to node-gyp to use node.exp when creating the shared library for a native module - Fixes to gyp related to copying files as covered in https://codereview.chromium.org/1368133002/patch/1/10001 - Pulling in updated gyp versions to Node and node-gyp - Pulling latest libuv These changes were done to minimize the change to other platforms by working within the existing structure to add the 2 step process for AIX without changing the process for other platforms. PR-URL: https://github.com/nodejs/node/pull/3114 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
2015-09-29 10:22:00 -04:00
}], # end aix section
build: fix various shared library build issues Node.js unofficially supports a shared library variant where the main node executable is a thin wrapper around node.dll/libnode.so. The key benefit of this is to support embedding Node.js in other applications. Since Node.js 12 there have been a number of issues preventing the shared library build from working correctly, primarily on Windows: * A number of functions used executables such as `mksnapshot` are not exported from `libnode.dll` using a `NODE_EXTERN` attribute * A dependency on the `Winmm` system library is missing * Incorrect defines on executable targets leads to `node.exe` claiming to export a number of functions that are actually in `libnode.dll` * Because `node.exe` attempts to export symbols, `node.lib` gets generated causing native extensions to try to link against `node.exe` not `libnode.dll`. * Similarly, because `node.dll` was renamed to `libnode.dll`, native extensions don't know to look for `libnode.lib` rather than `node.lib`. * On macOS an RPATH is added to find `libnode.dylib` relative to `node` in the same folder. This works fine from the `out/Release` folder but not from an installed prefix, where `node` will be in `bin/` and `libnode.dylib` will be in `lib/`. * Similarly on Linux, no RPATH is added so LD_LIBRARY_PATH needs setting correctly for `bin/node` to find `lib/libnode.so`. For the `libnode.lib` vs `node.lib` issue there are two possible options: 1. Ensure `node.lib` from `node.exe` does not get generated, and instead copy `libnode.lib` to `node.lib`. This means addons compiled when referencing the correct `node.lib` file will correctly depend on `libnode.dll`. The down side is that native addons compiled with stock Node.js will still try to resolve symbols against node.exe rather than libnode.dll. 2. After building `libnode.dll`, dump the exports using `dumpbin`, and process this to generate a `node.def` file to be linked into `node.exe` with the `/DEF:node.def` flag. The export entries in `node.def` will all read ``` my_symbol=libnode.my_symbol ``` so that `node.exe` will redirect all exported symbols back to `libnode.dll`. This has the benefit that addons compiled with stock Node.js will load correctly into `node.exe` from a shared library build, but means that every embedding executable also needs to perform this same trick. I went with the first option as it is the cleaner of the two solutions in my opinion. Projects wishing to generate a shared library variant of Node.js can now, for example, ``` .\vcbuild dll package vs ``` to generate a full node installation including `libnode.dll`, `Release\node.lib`, and all the necessary headers. Native addons can then be built against the shared library build easily by specifying the correct `nodedir` option. For example ``` >npx node-gyp configure --nodedir C:\Users\User\node\Release\node-v18.0.0-win-x64 ... >npx node-gyp build ... >dumpbin /dependents build\Release\binding.node Microsoft (R) COFF/PE Dumper Version 14.29.30136.0 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file build\Release\binding.node File Type: DLL Image has the following dependencies: KERNEL32.dll libnode.dll VCRUNTIME140.dll api-ms-win-crt-string-l1-1-0.dll api-ms-win-crt-stdio-l1-1-0.dll api-ms-win-crt-runtime-l1-1-0.dll ... ``` PR-URL: https://github.com/nodejs/node/pull/41850 Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Beth Griggs <bgriggs@redhat.com> Reviewed-By: Richard Lau <rlau@redhat.com>
2022-02-04 10:12:57 +00:00
['OS=="win" and node_shared=="true"', {
'targets': [
{
'target_name': 'gen_node_def',
'type': 'executable',
'sources': [
'tools/gen_node_def.cc'
],
},
{
'target_name': 'generate_node_def',
'dependencies': [
'gen_node_def',
'<(node_lib_target_name)',
],
'type': 'none',
'actions': [
{
'action_name': 'generate_node_def_action',
'inputs': [
'<(PRODUCT_DIR)/<(node_lib_target_name).dll'
],
'outputs': [
'<(PRODUCT_DIR)/<(node_core_target_name).def',
],
'action': [
'<(PRODUCT_DIR)/gen_node_def.exe',
'<@(_inputs)',
'<@(_outputs)',
],
},
],
},
],
}], # end win section
build: Updates for AIX npm support - part 1 This PR is the first step enabling support for native modules for AIX. The main issue is that unlike linux where all symbols within the Node executable are available to the shared library for a native module (npm), on AIX the symbols must be explicitly exported. In addition, when the shared library is built it must be linked using a list of the available symbols. This patch covers the changes need to: 1) Export the symbols when building the node executable 2) Generate the file listing the symbols that can be used when building the shared library. For AIX, it breaks the build process into 2 steps. The first builds a static library and then generates a node.exp file which contains the symbols from that library. The second builds the node executable and uses the node.exp file to specify which symbols should be exported. In addition, it save the node.exp file so that it can later be used in the creation of the shared library when building a native module. The following additional steps will be required in dependent projects to fully enable AIX for native modules and are being worked separately: - Updates to node-gyp to use node.exp when creating the shared library for a native module - Fixes to gyp related to copying files as covered in https://codereview.chromium.org/1368133002/patch/1/10001 - Pulling in updated gyp versions to Node and node-gyp - Pulling latest libuv These changes were done to minimize the change to other platforms by working within the existing structure to add the 2 step process for AIX without changing the process for other platforms. PR-URL: https://github.com/nodejs/node/pull/3114 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
2015-09-29 10:22:00 -04:00
], # end conditions block
2011-08-03 17:01:30 -07:00
}