node/tools/install.py

316 lines
9.7 KiB
Python
Raw Normal View History

#!/usr/bin/env python
from __future__ import print_function
import ast
import errno
import os
import shutil
import sys
# set at init time
node_prefix = '/usr/local' # PREFIX variable from Makefile
install_path = '' # base target directory (DESTDIR + PREFIX from Makefile)
target_defaults = None
variables = None
def abspath(*args):
path = os.path.join(*args)
return os.path.abspath(path)
def load_config():
with open('config.gypi') as f:
return ast.literal_eval(f.read())
def try_unlink(path):
try:
os.unlink(path)
except OSError as e:
if e.errno != errno.ENOENT: raise
def try_symlink(source_path, link_path):
print('symlinking %s -> %s' % (source_path, link_path))
try_unlink(link_path)
try_mkdir_r(os.path.dirname(link_path))
os.symlink(source_path, link_path)
def try_mkdir_r(path):
try:
os.makedirs(path)
except OSError as e:
if e.errno != errno.EEXIST: raise
def try_rmdir_r(path):
path = abspath(path)
while path.startswith(install_path):
try:
os.rmdir(path)
except OSError as e:
if e.errno == errno.ENOTEMPTY: return
if e.errno == errno.ENOENT: return
raise
path = abspath(path, '..')
def mkpaths(path, dst):
if dst.endswith('/'):
target_path = abspath(install_path, dst, os.path.basename(path))
else:
target_path = abspath(install_path, dst)
return path, target_path
def try_copy(path, dst):
source_path, target_path = mkpaths(path, dst)
print('installing %s' % target_path)
try_mkdir_r(os.path.dirname(target_path))
try_unlink(target_path) # prevent ETXTBSY errors
return shutil.copy2(source_path, target_path)
def try_remove(path, dst):
source_path, target_path = mkpaths(path, dst)
print('removing %s' % target_path)
try_unlink(target_path)
try_rmdir_r(os.path.dirname(target_path))
def install(paths, dst):
for path in paths:
try_copy(path, dst)
def uninstall(paths, dst):
for path in paths:
try_remove(path, dst)
def package_files(action, name, bins):
target_path = 'lib/node_modules/' + name + '/'
# don't install npm if the target path is a symlink, it probably means
# that a dev version of npm is installed there
if os.path.islink(abspath(install_path, target_path)): return
# npm has a *lot* of files and it'd be a pain to maintain a fixed list here
# so we walk its source directory instead...
root = 'deps/' + name
for dirname, subdirs, basenames in os.walk(root, topdown=True):
subdirs[:] = [subdir for subdir in subdirs if subdir != 'test']
paths = [os.path.join(dirname, basename) for basename in basenames]
action(paths, target_path + dirname[len(root) + 1:] + '/')
# create/remove symlinks
for bin_name, bin_target in bins.items():
link_path = abspath(install_path, 'bin/' + bin_name)
if action == uninstall:
action([link_path], 'bin/' + bin_name)
elif action == install:
try_symlink('../lib/node_modules/' + name + '/' + bin_target, link_path)
else:
assert 0 # unhandled action type
def npm_files(action):
package_files(action, 'npm', {
'npm': 'bin/npm-cli.js',
'npx': 'bin/npx-cli.js',
})
def corepack_files(action):
package_files(action, 'corepack', {
'corepack': 'dist/corepack.js',
# Not the default just yet:
# 'yarn': 'dist/yarn.js',
# 'yarnpkg': 'dist/yarn.js',
# 'pnpm': 'dist/pnpm.js',
# 'pnpx': 'dist/pnpx.js',
})
def subdir_files(path, dest, action):
ret = {}
for dirpath, dirnames, filenames in os.walk(path):
files_in_path = [dirpath + '/' + f for f in filenames if f.endswith('.h')]
ret[dest + dirpath.replace(path, '')] = files_in_path
for subdir, files_in_path in ret.items():
action(files_in_path, subdir + '/')
def files(action):
is_windows = sys.platform == 'win32'
output_file = 'node'
output_prefix = 'out/Release/'
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
if is_windows:
output_file += '.exe'
action([output_prefix + output_file], 'bin/' + output_file)
if 'true' == variables.get('node_shared'):
if is_windows:
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
action([output_prefix + 'libnode.dll'], 'bin/libnode.dll')
action([output_prefix + 'libnode.lib'], 'lib/libnode.lib')
else:
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
output_lib = 'libnode.' + variables.get('shlib_suffix')
action([output_prefix + output_lib], 'lib/' + output_lib)
if 'true' == variables.get('node_use_dtrace'):
action(['out/Release/node.d'], 'lib/dtrace/node.d')
action(['deps/v8/tools/gdbinit'], 'share/doc/node/')
action(['deps/v8/tools/lldb_commands.py'], 'share/doc/node/')
if 'freebsd' in sys.platform or 'openbsd' in sys.platform:
action(['doc/node.1'], 'man/man1/')
else:
action(['doc/node.1'], 'share/man/man1/')
if 'true' == variables.get('node_install_npm'):
npm_files(action)
if 'true' == variables.get('node_install_corepack'):
corepack_files(action)
headers(action)
def headers(action):
def wanted_v8_headers(files_arg, dest):
v8_headers = [
'deps/v8/include/cppgc/common.h',
'deps/v8/include/libplatform/libplatform.h',
'deps/v8/include/libplatform/libplatform-export.h',
'deps/v8/include/libplatform/v8-tracing.h',
'deps/v8/include/v8.h',
'deps/v8/include/v8-array-buffer.h',
'deps/v8/include/v8-callbacks.h',
'deps/v8/include/v8-container.h',
'deps/v8/include/v8-context.h',
'deps/v8/include/v8-data.h',
'deps/v8/include/v8-date.h',
'deps/v8/include/v8-debug.h',
'deps/v8/include/v8-embedder-heap.h',
'deps/v8/include/v8-embedder-state-scope.h',
'deps/v8/include/v8-exception.h',
'deps/v8/include/v8-extension.h',
'deps/v8/include/v8-external.h',
'deps/v8/include/v8-forward.h',
'deps/v8/include/v8-function-callback.h',
'deps/v8/include/v8-function.h',
'deps/v8/include/v8-initialization.h',
'deps/v8/include/v8-internal.h',
'deps/v8/include/v8-isolate.h',
'deps/v8/include/v8-json.h',
'deps/v8/include/v8-local-handle.h',
'deps/v8/include/v8-locker.h',
'deps/v8/include/v8-maybe.h',
'deps/v8/include/v8-memory-span.h',
'deps/v8/include/v8-message.h',
'deps/v8/include/v8-microtask-queue.h',
'deps/v8/include/v8-microtask.h',
'deps/v8/include/v8-object.h',
'deps/v8/include/v8-persistent-handle.h',
'deps/v8/include/v8-platform.h',
'deps/v8/include/v8-primitive-object.h',
'deps/v8/include/v8-primitive.h',
'deps/v8/include/v8-profiler.h',
'deps/v8/include/v8-promise.h',
'deps/v8/include/v8-proxy.h',
'deps/v8/include/v8-regexp.h',
'deps/v8/include/v8-script.h',
'deps/v8/include/v8-snapshot.h',
'deps/v8/include/v8-statistics.h',
'deps/v8/include/v8-template.h',
'deps/v8/include/v8-traced-handle.h',
'deps/v8/include/v8-typed-array.h',
'deps/v8/include/v8-unwinder.h',
'deps/v8/include/v8-value-serializer.h',
'deps/v8/include/v8-value.h',
'deps/v8/include/v8-version.h',
'deps/v8/include/v8-wasm.h',
'deps/v8/include/v8-weak-callback-info.h',
'deps/v8/include/v8config.h',
]
files_arg = [name for name in files_arg if name in v8_headers]
action(files_arg, dest)
def wanted_zoslib_headers(files_arg, dest):
import glob
zoslib_headers = glob.glob(zoslibinc + '/*.h')
files_arg = [name for name in files_arg if name in zoslib_headers]
action(files_arg, dest)
action([
'common.gypi',
'config.gypi',
'src/node.h',
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 21:55:26 +00:00
'src/node_api.h',
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 19:10:59 +00:00
'src/js_native_api.h',
'src/js_native_api_types.h',
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 21:55:26 +00:00
'src/node_api_types.h',
'src/node_buffer.h',
'src/node_object_wrap.h',
'src/node_version.h',
], 'include/node/')
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 14:22:00 +00:00
# Add the expfile that is created on AIX
if sys.platform.startswith('aix'):
action(['out/Release/node.exp'], 'include/node/')
subdir_files('deps/v8/include', 'include/node/', wanted_v8_headers)
if 'false' == variables.get('node_shared_libuv'):
subdir_files('deps/uv/include', 'include/node/', action)
if 'true' == variables.get('node_use_openssl') and \
'false' == variables.get('node_shared_openssl'):
subdir_files('deps/openssl/openssl/include/openssl', 'include/node/openssl/', action)
subdir_files('deps/openssl/config/archs', 'include/node/openssl/archs', action)
subdir_files('deps/openssl/config', 'include/node/openssl', action)
if 'false' == variables.get('node_shared_zlib'):
action([
'deps/zlib/zconf.h',
'deps/zlib/zlib.h',
], 'include/node/')
if sys.platform == 'zos':
zoslibinc = os.environ.get('ZOSLIB_INCLUDES')
if not zoslibinc:
raise RuntimeError('Environment variable ZOSLIB_INCLUDES is not set\n')
if not os.path.isfile(zoslibinc + '/zos-base.h'):
raise RuntimeError('ZOSLIB_INCLUDES is not set to a valid location\n')
subdir_files(zoslibinc, 'include/node/zoslib/', wanted_zoslib_headers)
def run(args):
global node_prefix, install_path, target_defaults, variables
# chdir to the project's top-level directory
os.chdir(abspath(os.path.dirname(__file__), '..'))
conf = load_config()
variables = conf['variables']
target_defaults = conf['target_defaults']
# argv[2] is a custom install prefix for packagers (think DESTDIR)
# argv[3] is a custom install prefix (think PREFIX)
# Difference is that dst_dir won't be included in shebang lines etc.
dst_dir = args[2] if len(args) > 2 else ''
if len(args) > 3:
node_prefix = args[3]
# install_path thus becomes the base target directory.
install_path = dst_dir + node_prefix + '/'
cmd = args[1] if len(args) > 1 else 'install'
if os.environ.get('HEADERS_ONLY'):
if cmd == 'install':
headers(install)
return
if cmd == 'uninstall':
headers(uninstall)
return
else:
if cmd == 'install':
files(install)
return
if cmd == 'uninstall':
files(uninstall)
return
raise RuntimeError('Bad command: %s\n' % cmd)
if __name__ == '__main__':
run(sys.argv[:])