0
0
mirror of https://github.com/nodejs/node.git synced 2024-12-01 16:10:02 +01:00
nodejs/node.gyp

1172 lines
38 KiB
Plaintext
Raw Normal View History

2011-08-04 02:01:30 +02:00
{
2011-08-04 08:36:27 +02:00
'variables': {
'v8_use_snapshot%': 'false',
'v8_trace_maps%': 0,
'node_use_dtrace%': 'false',
'node_use_etw%': 'false',
'node_no_browser_globals%': 'false',
build: speed up startup with V8 code cache This patch speeds up the startup time and reduce the startup memory footprint by using V8 code cache when comiling builtin modules. The current approach is demonstrated in the `with-code-cache` Makefile target (no corresponding Windows target at the moment). 1. Build the binary normally (`src/node_code_cache_stub.cc` is used), by now `internalBinding('code_cache')` is an empty object 2. Run `tools/generate_code_cache.js` with the binary, which generates the code caches by reading source code of builtin modules off source code exposed by `require('internal/bootstrap/cache').builtinSource` and then generate a C++ file containing static char arrays of the code cache, using a format similar to `node_javascript.cc` 3. Run `configure` with the `--code-cache-path` option so that the newly generated C++ file will be used when compiling the new binary. The generated C++ file will put the cache into the `internalBinding('code_cache')` object with the module ids as keys 4. The new binary tries to read the code cache from `internalBinding('code_cache')` and use it to compile builtin modules. If the cache is used, it will put the id into `require('internal/bootstrap/cache').compiledWithCache` for bookkeeping, otherwise the id will be pushed into `require('internal/bootstrap/cache').compiledWithoutCache` This patch also added tests that verify the code cache is generated and used when compiling builtin modules. The binary with code cache: - Is ~1MB bigger than the binary without code cahe - Consumes ~1MB less memory during start up - Starts up about 60% faster PR-URL: https://github.com/nodejs/node/pull/21405 Reviewed-By: John-David Dalton <john.david.dalton@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Gus Caplan <me@gus.host>
2018-06-18 19:02:57 +02:00
'node_code_cache_path%': '',
'node_use_v8_platform%': 'true',
'node_use_bundled_v8%': 'true',
'node_shared%': 'false',
'force_dynamic_crt%': 0,
'node_module_version%': '',
2012-02-27 00:02:21 +01: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 16:22:00 +02:00
'node_core_target_name%': 'node',
'node_lib_target_name%': 'node_lib',
'node_intermediate_lib_type%': 'static_library',
2011-09-05 01:01:53 +02:00
'library_files': [
'lib/internal/per_context.js',
build: speed up startup with V8 code cache This patch speeds up the startup time and reduce the startup memory footprint by using V8 code cache when comiling builtin modules. The current approach is demonstrated in the `with-code-cache` Makefile target (no corresponding Windows target at the moment). 1. Build the binary normally (`src/node_code_cache_stub.cc` is used), by now `internalBinding('code_cache')` is an empty object 2. Run `tools/generate_code_cache.js` with the binary, which generates the code caches by reading source code of builtin modules off source code exposed by `require('internal/bootstrap/cache').builtinSource` and then generate a C++ file containing static char arrays of the code cache, using a format similar to `node_javascript.cc` 3. Run `configure` with the `--code-cache-path` option so that the newly generated C++ file will be used when compiling the new binary. The generated C++ file will put the cache into the `internalBinding('code_cache')` object with the module ids as keys 4. The new binary tries to read the code cache from `internalBinding('code_cache')` and use it to compile builtin modules. If the cache is used, it will put the id into `require('internal/bootstrap/cache').compiledWithCache` for bookkeeping, otherwise the id will be pushed into `require('internal/bootstrap/cache').compiledWithoutCache` This patch also added tests that verify the code cache is generated and used when compiling builtin modules. The binary with code cache: - Is ~1MB bigger than the binary without code cahe - Consumes ~1MB less memory during start up - Starts up about 60% faster PR-URL: https://github.com/nodejs/node/pull/21405 Reviewed-By: John-David Dalton <john.david.dalton@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Gus Caplan <me@gus.host>
2018-06-18 19:02:57 +02:00
'lib/internal/bootstrap/cache.js',
'lib/internal/bootstrap/loaders.js',
'lib/internal/bootstrap/node.js',
'lib/async_hooks.js',
2011-09-05 01:01:53 +02:00
'lib/assert.js',
'lib/buffer.js',
2011-10-11 22:16:33 +02:00
'lib/child_process.js',
2011-09-05 01:01:53 +02:00
'lib/console.js',
'lib/constants.js',
'lib/crypto.js',
2011-10-12 23:51:25 +02:00
'lib/cluster.js',
2011-10-11 22:26:41 +02:00
'lib/dgram.js',
2011-10-11 22:21:30 +02:00
'lib/dns.js',
Domain feature This is a squashed commit of the main work done on the domains-wip branch. The original commit messages are preserved for posterity: * Implicitly add EventEmitters to active domain * Implicitly add timers to active domain * domain: add members, remove ctor cb * Don't hijack bound callbacks for Domain error events * Add dispose method * Add domain.remove(ee) method * A test of multiple domains in process at once * Put the active domain on the process object * Only intercept error arg if explicitly requested * Typo * Don't auto-add new domains to the current domain While an automatic parent/child relationship is sort of neat, and leads to some nice error-bubbling characteristics, it also results in keeping a reference to every EE and timer created, unless domains are explicitly disposed of. * Explicitly adding one domain to another is still fine, of course. * Don't allow circular domain->domain memberships * Disposing of a domain removes it from its parent * Domain disposal turns functions into no-ops * More documentation of domains * More thorough dispose() semantics * An example using domains in an HTTP server * Don't handle errors on a disposed domain * Need to push, even if the same domain is entered multiple times * Array.push is too slow for the EE Ctor * lint domain * domain: docs * Also call abort and destroySoon to clean up event emitters * domain: Wrap destroy methods in a try/catch * Attach tick callbacks to active domain * domain: Only implicitly bind timers, not explicitly * domain: Don't fire timers when disposed. * domain: Simplify naming so that MakeCallback works on Timers * Add setInterval and nextTick to domain test * domain: Make stack private
2012-04-07 01:26:18 +02:00
'lib/domain.js',
2011-09-05 01:01:53 +02:00
'lib/events.js',
'lib/fs.js',
'lib/http.js',
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 19:17:16 +02:00
'lib/http2.js',
2013-04-11 23:47:15 +02:00
'lib/_http_agent.js',
'lib/_http_client.js',
'lib/_http_common.js',
'lib/_http_incoming.js',
'lib/_http_outgoing.js',
'lib/_http_server.js',
2011-09-05 01:01:53 +02:00
'lib/https.js',
'lib/inspector.js',
2011-09-05 01:01:53 +02:00
'lib/module.js',
2011-10-11 22:07:14 +02:00
'lib/net.js',
2011-09-05 01:01:53 +02:00
'lib/os.js',
'lib/path.js',
'lib/perf_hooks.js',
'lib/process.js',
2011-09-05 01:01:53 +02:00
'lib/punycode.js',
'lib/querystring.js',
'lib/readline.js',
'lib/repl.js',
'lib/stream.js',
2012-10-03 00:44:50 +02:00
'lib/_stream_readable.js',
'lib/_stream_writable.js',
'lib/_stream_duplex.js',
'lib/_stream_transform.js',
'lib/_stream_passthrough.js',
'lib/_stream_wrap.js',
2011-09-05 01:01:53 +02:00
'lib/string_decoder.js',
'lib/sys.js',
2011-10-11 22:07:14 +02:00
'lib/timers.js',
2011-09-05 01:01:53 +02:00
'lib/tls.js',
'lib/_tls_common.js',
'lib/_tls_wrap.js',
'lib/trace_events.js',
2011-10-11 22:41:33 +02:00
'lib/tty.js',
2011-09-05 01:01:53 +02:00
'lib/url.js',
'lib/util.js',
'lib/v8.js',
2011-09-05 01:01:53 +02:00
'lib/vm.js',
'lib/worker_threads.js',
2011-09-07 01:13:05 +02:00
'lib/zlib.js',
'lib/internal/assert.js',
'lib/internal/async_hooks.js',
'lib/internal/bash_completion.js',
'lib/internal/buffer.js',
'lib/internal/cli_table.js',
'lib/internal/child_process.js',
'lib/internal/cluster/child.js',
'lib/internal/cluster/master.js',
'lib/internal/cluster/round_robin_handle.js',
'lib/internal/cluster/shared_handle.js',
'lib/internal/cluster/utils.js',
'lib/internal/cluster/worker.js',
'lib/internal/crypto/certificate.js',
'lib/internal/crypto/cipher.js',
'lib/internal/crypto/diffiehellman.js',
'lib/internal/crypto/hash.js',
'lib/internal/crypto/keygen.js',
'lib/internal/crypto/pbkdf2.js',
'lib/internal/crypto/random.js',
'lib/internal/crypto/scrypt.js',
'lib/internal/crypto/sig.js',
'lib/internal/crypto/util.js',
'lib/internal/constants.js',
'lib/internal/dgram.js',
'lib/internal/dns/promises.js',
'lib/internal/dns/utils.js',
'lib/internal/domexception.js',
'lib/internal/encoding.js',
'lib/internal/errors.js',
'lib/internal/error-serdes.js',
'lib/internal/fixed_queue.js',
'lib/internal/freelist.js',
'lib/internal/fs/promises.js',
'lib/internal/fs/read_file_context.js',
'lib/internal/fs/streams.js',
'lib/internal/fs/sync_write_stream.js',
'lib/internal/fs/utils.js',
'lib/internal/fs/watchers.js',
'lib/internal/http.js',
inspector: enable async stack traces Implement a special async_hooks listener that forwards information about async tasks to V8Inspector asyncTask* API, thus enabling DevTools feature "async stack traces". The feature is enabled only on 64bit platforms due to a technical limitation of V8 Inspector: inspector uses a pointer as a task id, while async_hooks use 64bit numbers as ids. To avoid performance penalty of async_hooks when not debugging, the new listener is enabled only when the process enters a debug mode: - When the process is started with `--inspect` or `--inspect-brk`, the listener is enabled immediately and async stack traces lead all the way to the first tick of the event loop. - When the debug mode is enabled via SIGUSR1 or `_debugProcess()`, the listener is enabled together with the debugger. As a result, only async operations started after the signal was received will be correctly observed and reported to V8 Inspector. For example, a `setInterval()` called in the first tick of the event will not be shown in the async stack trace when the callback is invoked. This behaviour is consistent with Chrome DevTools. Last but not least, this commit fixes handling of InspectorAgent's internal property `enabled_` to ensure it's set back to `false` after the debugger is deactivated (typically via `process._debugEnd()`). Fixes: https://github.com/nodejs/node/issues/11370 PR-URL: https://github.com/nodejs/node/pull/13870 Reviewed-by: Timothy Gu <timothygu99@gmail.com> Reviewed-by: Anna Henningsen <anna@addaleax.net>
2017-07-17 16:51:26 +02:00
'lib/internal/inspector_async_hook.js',
'lib/internal/linkedlist.js',
'lib/internal/modules/cjs/helpers.js',
'lib/internal/modules/cjs/loader.js',
'lib/internal/modules/esm/loader.js',
'lib/internal/modules/esm/create_dynamic_module.js',
'lib/internal/modules/esm/default_resolve.js',
'lib/internal/modules/esm/module_job.js',
'lib/internal/modules/esm/module_map.js',
'lib/internal/modules/esm/translators.js',
'lib/internal/safe_globals.js',
'lib/internal/net.js',
'lib/internal/print_help.js',
'lib/internal/priority_queue.js',
'lib/internal/process/esm_loader.js',
process: split bootstrappers by threads that can run them This patch split part of the bootstrappers into three files: - `lib/internal/process/main_thread_only.js`: contains bootstrappers that can only be run in the main thread, including - `setupStdio` for the main thread that sets up `process.stdin`, `process.stdout`, `process.error` that may interact with external resources, e.g. TTY/File/Pipe/TCP sockets - `setupProcessMethods` that setup methods changing process-global states, e.g. `process.chdir`, `process.umask`, `process.setuid` - `setupSignalHandlers` - `setupChildProcessIpcChannel` that setup `process.send` for child processes. - `lib/internal/process/worker_thread_only.js`: contains bootstrappers that can only be run in the worker threads, including - `setupStdio` for the worker thread that are streams to be manipulated or piped to the parent thread - `lib/internal/process/per_thread.js`: contains bootstrappers that can be run in all threads, including: - `setupAssert` for `process.assert` - `setupCpuUsage` for `process.cpuUsage` - `setupHrtime` for `process.hrtime` and `process.hrtime.bigint` - `setupMemoryUsage` for `process.memoryUsage` - `setupConfig` for `process.config` - `setupKillAndExit` for `process.kill` and `process.exit` - `setupRawDebug` for `process._rawDebug` - `setupUncaughtExceptionCapture` for `process.setUncaughtExceptionCaptureCallback` and `process.hasUncaughtExceptionCaptureCallback` Hopefully in the future we can sort more bootstrappers in `boostrap/node.js` into these three files and further group them into functions that can be run before creating the snapshot / after loading the snapshot. This patch also moves most of the `isMainThread` conditionals into the main bootstrapper instead of letting them scattered around special-casing different implementations. PR-URL: https://github.com/nodejs/node/pull/21378 Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
2018-06-17 18:40:58 +02:00
'lib/internal/process/main_thread_only.js',
'lib/internal/process/next_tick.js',
process: split bootstrappers by threads that can run them This patch split part of the bootstrappers into three files: - `lib/internal/process/main_thread_only.js`: contains bootstrappers that can only be run in the main thread, including - `setupStdio` for the main thread that sets up `process.stdin`, `process.stdout`, `process.error` that may interact with external resources, e.g. TTY/File/Pipe/TCP sockets - `setupProcessMethods` that setup methods changing process-global states, e.g. `process.chdir`, `process.umask`, `process.setuid` - `setupSignalHandlers` - `setupChildProcessIpcChannel` that setup `process.send` for child processes. - `lib/internal/process/worker_thread_only.js`: contains bootstrappers that can only be run in the worker threads, including - `setupStdio` for the worker thread that are streams to be manipulated or piped to the parent thread - `lib/internal/process/per_thread.js`: contains bootstrappers that can be run in all threads, including: - `setupAssert` for `process.assert` - `setupCpuUsage` for `process.cpuUsage` - `setupHrtime` for `process.hrtime` and `process.hrtime.bigint` - `setupMemoryUsage` for `process.memoryUsage` - `setupConfig` for `process.config` - `setupKillAndExit` for `process.kill` and `process.exit` - `setupRawDebug` for `process._rawDebug` - `setupUncaughtExceptionCapture` for `process.setUncaughtExceptionCaptureCallback` and `process.hasUncaughtExceptionCaptureCallback` Hopefully in the future we can sort more bootstrappers in `boostrap/node.js` into these three files and further group them into functions that can be run before creating the snapshot / after loading the snapshot. This patch also moves most of the `isMainThread` conditionals into the main bootstrapper instead of letting them scattered around special-casing different implementations. PR-URL: https://github.com/nodejs/node/pull/21378 Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
2018-06-17 18:40:58 +02:00
'lib/internal/process/per_thread.js',
'lib/internal/process/promises.js',
'lib/internal/process/stdio.js',
process: add 'warning' event and process.emitWarning() In several places throughout the code we write directly to stderr to report warnings (deprecation, possible eventemitter memory leak). The current design of simply dumping the text to stderr is less than ideal. This PR introduces a new "process warnings" mechanism that emits 'warning' events on the global process object. These are invoked with a `warning` argument whose value is an Error object. By default, these warnings will be printed to stderr. This can be suppressed using the `--no-warnings` and `--no-deprecation` command line flags. For warnings, the 'warning' event will still be emitted by the process, allowing applications to handle the warnings in custom ways. The existing `--no-deprecation` flag will continue to supress all deprecation output generated by the core lib. The `--trace-warnings` command line flag will tell Node.js to print the full stack trace of warnings as part of the default handling. The existing `--no-deprecation`, `--throw-deprecation` and `--trace-deprecation` flags continue to work as they currently do, but the exact output of the warning message is modified to occur on process.nextTick(). The stack trace for the warnings and deprecations preserve and point to the correct call site. A new `process.emitWarning()` API is provided to permit userland to emit warnings and deprecations using the same consistent mechanism. Test cases and documentation are included. PR-URL: https://github.com/nodejs/node/pull/4782 Reviewed-By: Rod Vagg <rod@vagg.org> Reviewed-By: Wyatt Preul <wpreul@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
2016-01-20 20:38:35 +01:00
'lib/internal/process/warning.js',
process: split bootstrappers by threads that can run them This patch split part of the bootstrappers into three files: - `lib/internal/process/main_thread_only.js`: contains bootstrappers that can only be run in the main thread, including - `setupStdio` for the main thread that sets up `process.stdin`, `process.stdout`, `process.error` that may interact with external resources, e.g. TTY/File/Pipe/TCP sockets - `setupProcessMethods` that setup methods changing process-global states, e.g. `process.chdir`, `process.umask`, `process.setuid` - `setupSignalHandlers` - `setupChildProcessIpcChannel` that setup `process.send` for child processes. - `lib/internal/process/worker_thread_only.js`: contains bootstrappers that can only be run in the worker threads, including - `setupStdio` for the worker thread that are streams to be manipulated or piped to the parent thread - `lib/internal/process/per_thread.js`: contains bootstrappers that can be run in all threads, including: - `setupAssert` for `process.assert` - `setupCpuUsage` for `process.cpuUsage` - `setupHrtime` for `process.hrtime` and `process.hrtime.bigint` - `setupMemoryUsage` for `process.memoryUsage` - `setupConfig` for `process.config` - `setupKillAndExit` for `process.kill` and `process.exit` - `setupRawDebug` for `process._rawDebug` - `setupUncaughtExceptionCapture` for `process.setUncaughtExceptionCaptureCallback` and `process.hasUncaughtExceptionCaptureCallback` Hopefully in the future we can sort more bootstrappers in `boostrap/node.js` into these three files and further group them into functions that can be run before creating the snapshot / after loading the snapshot. This patch also moves most of the `isMainThread` conditionals into the main bootstrapper instead of letting them scattered around special-casing different implementations. PR-URL: https://github.com/nodejs/node/pull/21378 Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
2018-06-17 18:40:58 +02:00
'lib/internal/process/worker_thread_only.js',
'lib/internal/querystring.js',
'lib/internal/process/write-coverage.js',
'lib/internal/process/coverage.js',
'lib/internal/queue_microtask.js',
'lib/internal/readline.js',
'lib/internal/repl.js',
'lib/internal/repl/await.js',
'lib/internal/repl/recoverable.js',
'lib/internal/socket_list.js',
'lib/internal/test/binding.js',
'lib/internal/test/heap.js',
'lib/internal/test/unicode.js',
'lib/internal/timers.js',
'lib/internal/tls.js',
'lib/internal/trace_events_async_hooks.js',
'lib/internal/tty.js',
'lib/internal/url.js',
'lib/internal/util.js',
'lib/internal/util/comparisons.js',
'lib/internal/util/inspector.js',
'lib/internal/util/types.js',
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 19:17:16 +02:00
'lib/internal/http2/core.js',
'lib/internal/http2/compat.js',
'lib/internal/http2/util.js',
'lib/internal/v8_prof_polyfill.js',
'lib/internal/v8_prof_processor.js',
'lib/internal/validators.js',
'lib/internal/stream_base_commons.js',
'lib/internal/vm/source_text_module.js',
'lib/internal/worker.js',
'lib/internal/streams/lazy_transform.js',
'lib/internal/streams/async_iterator.js',
'lib/internal/streams/buffer_list.js',
'lib/internal/streams/duplexpair.js',
'lib/internal/streams/legacy.js',
'lib/internal/streams/destroy.js',
'lib/internal/streams/state.js',
'lib/internal/streams/pipeline.js',
'lib/internal/streams/end-of-stream.js',
'lib/internal/wrap_js_stream.js',
'deps/v8/tools/splaytree.js',
'deps/v8/tools/codemap.js',
'deps/v8/tools/consarray.js',
'deps/v8/tools/csvparser.js',
'deps/v8/tools/profile.js',
'deps/v8/tools/profile_view.js',
'deps/v8/tools/logreader.js',
'deps/v8/tools/arguments.js',
'deps/v8/tools/tickprocessor.js',
'deps/v8/tools/SourceMap.js',
'deps/v8/tools/tickprocessor-driver.js',
'deps/node-inspect/lib/_inspect.js',
'deps/node-inspect/lib/internal/inspect_client.js',
'deps/node-inspect/lib/internal/inspect_repl.js',
'deps/acorn/dist/acorn.js',
'deps/acorn/dist/walk.js',
2011-09-05 01:01:53 +02:00
],
'conditions': [
[ '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-04 08:36:27 +02:00
},
2011-08-04 02:01:30 +02:00
'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 16:22:00 +02:00
'target_name': '<(node_core_target_name)',
'type': 'executable',
'sources': [
'src/node_main.cc'
],
'includes': [
'node.gypi'
],
'include_dirs': [
'src',
'deps/v8/include',
],
# - "C4244: conversion from 'type1' to 'type2', possible loss of data"
# Ususaly safe. Disable for `dep`, enable for `src`
'msvs_disabled_warnings!': [4244],
'conditions': [
[ '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)' ],
}],
[ '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)',
],
},
'msvs_settings': {
'VCLinkerTool': {
'AdditionalOptions': [
'/WHOLEARCHIVE:<(node_core_target_name)<(STATIC_LIB_SUFFIX)',
],
},
},
'conditions': [
['OS!="aix"', {
'ldflags': [
'-Wl,--whole-archive,<(obj_dir)/<(STATIC_LIB_PREFIX)'
'<(node_core_target_name)<(STATIC_LIB_SUFFIX)',
'-Wl,--no-whole-archive',
],
}],
[ 'OS=="win"', {
'sources': [ 'src/res/node.rc' ],
'conditions': [
[ 'node_use_etw=="true"', {
'sources': [
'tools/msvs/genfiles/node_etw_provider.rc'
],
}]
],
}],
],
}],
[ 'node_shared=="true"', {
'xcode_settings': {
'OTHER_LDFLAGS': [ '-Wl,-rpath,@loader_path', ],
},
}],
[ 'node_intermediate_lib_type=="shared_library" and OS=="win"', {
# On Windows, having the same name for both executable and shared
# lib causes filename collision. Need a different PRODUCT_NAME for
# the executable and rename it back to node.exe later
'product_name': '<(node_core_target_name)-win',
}],
],
},
{
'target_name': '<(node_lib_target_name)',
'type': '<(node_intermediate_lib_type)',
'product_name': '<(node_core_target_name)',
2011-08-04 08:36:27 +02:00
2011-08-04 02:01:30 +02:00
'dependencies': [
2011-08-05 01:40:07 +02:00
'node_js2c#host',
2011-08-04 02:01:30 +02:00
],
2011-08-05 01:40:07 +02:00
'includes': [
'node.gypi'
],
2011-08-05 01:40:07 +02:00
'include_dirs': [
2011-08-08 21:11:48 +02:00
'src',
'<(SHARED_INTERMEDIATE_DIR)' # for node_natives.h
2011-08-05 01:40:07 +02:00
],
2011-08-04 02:01:30 +02:00
'sources': [
'src/async_wrap.cc',
'src/bootstrapper.cc',
'src/callback_scope.cc',
2011-08-08 21:11:48 +02:00
'src/cares_wrap.cc',
'src/connection_wrap.cc',
'src/connect_wrap.cc',
'src/debug_utils.cc',
'src/env.cc',
'src/exceptions.cc',
'src/fs_event_wrap.cc',
2011-08-08 21:11:48 +02:00
'src/handle_wrap.cc',
'src/heap_utils.cc',
'src/js_stream.cc',
'src/module_wrap.cc',
2011-08-08 21:11:48 +02: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 22:55:26 +01:00
'src/node_api.cc',
'src/node_api.h',
'src/node_api_types.h',
2011-08-08 21:11:48 +02:00
'src/node_buffer.cc',
'src/node_config.cc',
2011-08-08 21:11:48 +02: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 06:34:12 +02:00
'src/node_contextify.cc',
'src/node_domain.cc',
'src/node_encoding.cc',
'src/node_errors.h',
2011-08-08 21:11:48 +02:00
'src/node_file.cc',
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 19:17:16 +02:00
'src/node_http2.cc',
2011-08-08 21:11:48 +02:00
'src/node_http_parser.cc',
'src/node_messaging.cc',
'src/node_options.cc',
2011-08-08 21:11:48 +02:00
'src/node_os.cc',
'src/node_platform.cc',
'src/node_perf.cc',
'src/node_postmortem_metadata.cc',
'src/node_process.cc',
'src/node_serdes.cc',
'src/node_trace_events.cc',
'src/node_types.cc',
'src/node_url.cc',
'src/node_util.cc',
'src/node_v8.cc',
'src/node_stat_watcher.cc',
'src/node_watchdog.cc',
'src/node_worker.cc',
2011-09-07 01:13:05 +02:00
'src/node_zlib.cc',
build, i18n: improve Intl build, add "--with-intl" The two main goals of this change are: - To make it easier to build the Intl option using ICU (particularly, using a newer ICU than v8/Chromium's version) - To enable a much smaller ICU build with only English support The goal here is to get node.js binaries built this way by default so that the Intl API can be used. Additional data can be added at execution time (see Readme and wiki) More details are at https://github.com/joyent/node/pull/7719 In particular, this change adds the "--with-intl=" configure option to provide more ways of building "Intl": - "full-icu" picks up an ICU from deps/icu - "small-icu" is similar, but builds only English - "system-icu" uses pkg-config to find an installed ICU - "none" does nothing (no Intl) For Windows builds, the "full-icu" or "small-icu" options are added to vcbuild.bat. Note that the existing "--with-icu-path" option is not removed from configure, but may not be used alongside the new option. Wiki changes have already been made on https://github.com/joyent/node/wiki/Installation and a new page created at https://github.com/joyent/node/wiki/Intl (marked as provisional until this change lands.) Summary of changes: * README.md : doc updates * .gitignore : added "deps/icu" as this is the location where ICU is unpacked to. * Makefile : added the tools/icu/* files to cpplint, but excluded a problematic file. * configure : added the "--with-intl" option mentioned above. Calculate at config time the list of ICU source files to use and data packaging options. * node.gyp : add the new files src/node_i18n.cc/.h as well as ICU linkage. * src/node.cc : add call into node::i18n::InitializeICUDirectory(icu_data_dir) as well as new --icu-data-dir option and NODE_ICU_DATA env variable to configure ICU data loading. This loading is only relevant in the "small" configuration. * src/node_i18n.cc : new source file for the above Initialize.. function, to setup ICU as needed. * tools/icu : new directory with some tools needed for this build. * tools/icu/icu-generic.gyp : new .gyp file that builds ICU in some new ways, both on unix/mac and windows. * tools/icu/icu-system.gyp : new .gyp file to build node against a pkg-config detected ICU. * tools/icu/icu_small.json : new config file for the "English-only" small build. * tools/icu/icutrim.py : new tool for trimming down ICU data. Reads the above .json file. * tools/icu/iculslocs.cc : new tool for repairing ICU data manifests after trim operation. * tools/icu/no-op.cc : dummy file to force .gyp into using a C++ linker. * vcbuild.bat : added small-icu and full-icu options, to call into configure. * Fixed toolset dependencies, see https://github.com/joyent/node/pull/7719#issuecomment-54641687 Note that because of a bug in gyp {CC,CXX}_host must also be set. Otherwise gcc/g++ will be used by default for part of the build. Reviewed-by: Trevor Norris <trev.norris@gmail.com> Reviewed-by: Fedor Indutny <fedor@indutny.com>
2014-09-05 07:03:24 +02:00
'src/node_i18n.cc',
2011-08-08 21:11:48 +02:00
'src/pipe_wrap.cc',
'src/process_wrap.cc',
'src/sharedarraybuffer_metadata.cc',
'src/signal_wrap.cc',
'src/spawn_sync.cc',
'src/string_bytes.cc',
'src/string_decoder.cc',
'src/stream_base.cc',
'src/stream_pipe.cc',
2011-08-08 21:11:48 +02:00
'src/stream_wrap.cc',
'src/tcp_wrap.cc',
'src/timers.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 22:38:07 +02:00
'src/tty_wrap.cc',
2011-08-25 01:20:08 +02: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/async_wrap.h',
'src/async_wrap-inl.h',
'src/base_object.h',
'src/base_object-inl.h',
'src/connection_wrap.h',
'src/connect_wrap.h',
'src/debug_utils.h',
'src/env.h',
'src/env-inl.h',
'src/handle_wrap.h',
'src/js_stream.h',
'src/module_wrap.h',
'src/node.h',
'src/node_buffer.h',
build: speed up startup with V8 code cache This patch speeds up the startup time and reduce the startup memory footprint by using V8 code cache when comiling builtin modules. The current approach is demonstrated in the `with-code-cache` Makefile target (no corresponding Windows target at the moment). 1. Build the binary normally (`src/node_code_cache_stub.cc` is used), by now `internalBinding('code_cache')` is an empty object 2. Run `tools/generate_code_cache.js` with the binary, which generates the code caches by reading source code of builtin modules off source code exposed by `require('internal/bootstrap/cache').builtinSource` and then generate a C++ file containing static char arrays of the code cache, using a format similar to `node_javascript.cc` 3. Run `configure` with the `--code-cache-path` option so that the newly generated C++ file will be used when compiling the new binary. The generated C++ file will put the cache into the `internalBinding('code_cache')` object with the module ids as keys 4. The new binary tries to read the code cache from `internalBinding('code_cache')` and use it to compile builtin modules. If the cache is used, it will put the id into `require('internal/bootstrap/cache').compiledWithCache` for bookkeeping, otherwise the id will be pushed into `require('internal/bootstrap/cache').compiledWithoutCache` This patch also added tests that verify the code cache is generated and used when compiling builtin modules. The binary with code cache: - Is ~1MB bigger than the binary without code cahe - Consumes ~1MB less memory during start up - Starts up about 60% faster PR-URL: https://github.com/nodejs/node/pull/21405 Reviewed-By: John-David Dalton <john.david.dalton@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Gus Caplan <me@gus.host>
2018-06-18 19:02:57 +02:00
'src/node_code_cache.h',
'src/node_constants.h',
'src/node_contextify.h',
'src/node_file.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 19:17:16 +02:00
'src/node_http2.h',
'src/node_http2_state.h',
'src/node_internals.h',
'src/node_javascript.h',
'src/node_messaging.h',
'src/node_mutex.h',
'src/node_options.h',
'src/node_options-inl.h',
'src/node_perf.h',
'src/node_perf_common.h',
'src/node_persistent.h',
'src/node_platform.h',
'src/node_root_certs.h',
'src/node_version.h',
'src/node_watchdog.h',
'src/node_wrap.h',
'src/node_revert.h',
build, i18n: improve Intl build, add "--with-intl" The two main goals of this change are: - To make it easier to build the Intl option using ICU (particularly, using a newer ICU than v8/Chromium's version) - To enable a much smaller ICU build with only English support The goal here is to get node.js binaries built this way by default so that the Intl API can be used. Additional data can be added at execution time (see Readme and wiki) More details are at https://github.com/joyent/node/pull/7719 In particular, this change adds the "--with-intl=" configure option to provide more ways of building "Intl": - "full-icu" picks up an ICU from deps/icu - "small-icu" is similar, but builds only English - "system-icu" uses pkg-config to find an installed ICU - "none" does nothing (no Intl) For Windows builds, the "full-icu" or "small-icu" options are added to vcbuild.bat. Note that the existing "--with-icu-path" option is not removed from configure, but may not be used alongside the new option. Wiki changes have already been made on https://github.com/joyent/node/wiki/Installation and a new page created at https://github.com/joyent/node/wiki/Intl (marked as provisional until this change lands.) Summary of changes: * README.md : doc updates * .gitignore : added "deps/icu" as this is the location where ICU is unpacked to. * Makefile : added the tools/icu/* files to cpplint, but excluded a problematic file. * configure : added the "--with-intl" option mentioned above. Calculate at config time the list of ICU source files to use and data packaging options. * node.gyp : add the new files src/node_i18n.cc/.h as well as ICU linkage. * src/node.cc : add call into node::i18n::InitializeICUDirectory(icu_data_dir) as well as new --icu-data-dir option and NODE_ICU_DATA env variable to configure ICU data loading. This loading is only relevant in the "small" configuration. * src/node_i18n.cc : new source file for the above Initialize.. function, to setup ICU as needed. * tools/icu : new directory with some tools needed for this build. * tools/icu/icu-generic.gyp : new .gyp file that builds ICU in some new ways, both on unix/mac and windows. * tools/icu/icu-system.gyp : new .gyp file to build node against a pkg-config detected ICU. * tools/icu/icu_small.json : new config file for the "English-only" small build. * tools/icu/icutrim.py : new tool for trimming down ICU data. Reads the above .json file. * tools/icu/iculslocs.cc : new tool for repairing ICU data manifests after trim operation. * tools/icu/no-op.cc : dummy file to force .gyp into using a C++ linker. * vcbuild.bat : added small-icu and full-icu options, to call into configure. * Fixed toolset dependencies, see https://github.com/joyent/node/pull/7719#issuecomment-54641687 Note that because of a bug in gyp {CC,CXX}_host must also be set. Otherwise gcc/g++ will be used by default for part of the build. Reviewed-by: Trevor Norris <trev.norris@gmail.com> Reviewed-by: Fedor Indutny <fedor@indutny.com>
2014-09-05 07:03:24 +02:00
'src/node_i18n.h',
'src/node_worker.h',
'src/memory_tracker.h',
'src/memory_tracker-inl.h',
'src/pipe_wrap.h',
'src/tty_wrap.h',
'src/tcp_wrap.h',
'src/udp_wrap.h',
'src/req_wrap.h',
'src/req_wrap-inl.h',
'src/sharedarraybuffer_metadata.h',
'src/string_bytes.h',
'src/string_decoder.h',
'src/string_decoder-inl.h',
'src/stream_base.h',
'src/stream_base-inl.h',
'src/stream_pipe.h',
'src/stream_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/traced_value.h',
'src/util.h',
'src/util-inl.h',
'deps/http_parser/http_parser.h',
'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)',
2011-10-28 12:10:24 +02:00
# node.gyp is added to the project by default.
'common.gypi',
'<(SHARED_INTERMEDIATE_DIR)/node_javascript.cc',
2011-08-05 01:40:07 +02:00
],
'variables': {
'openssl_system_ca_path%': '',
},
2011-08-05 01:40:07 +02: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-04 02:01:30 +02:00
],
# - "C4244: conversion from 'type1' to 'type2', possible loss of data"
# Ususaly safe. Disable for `dep`, enable for `src`
'msvs_disabled_warnings!': [4244],
'conditions': [
build: speed up startup with V8 code cache This patch speeds up the startup time and reduce the startup memory footprint by using V8 code cache when comiling builtin modules. The current approach is demonstrated in the `with-code-cache` Makefile target (no corresponding Windows target at the moment). 1. Build the binary normally (`src/node_code_cache_stub.cc` is used), by now `internalBinding('code_cache')` is an empty object 2. Run `tools/generate_code_cache.js` with the binary, which generates the code caches by reading source code of builtin modules off source code exposed by `require('internal/bootstrap/cache').builtinSource` and then generate a C++ file containing static char arrays of the code cache, using a format similar to `node_javascript.cc` 3. Run `configure` with the `--code-cache-path` option so that the newly generated C++ file will be used when compiling the new binary. The generated C++ file will put the cache into the `internalBinding('code_cache')` object with the module ids as keys 4. The new binary tries to read the code cache from `internalBinding('code_cache')` and use it to compile builtin modules. If the cache is used, it will put the id into `require('internal/bootstrap/cache').compiledWithCache` for bookkeeping, otherwise the id will be pushed into `require('internal/bootstrap/cache').compiledWithoutCache` This patch also added tests that verify the code cache is generated and used when compiling builtin modules. The binary with code cache: - Is ~1MB bigger than the binary without code cahe - Consumes ~1MB less memory during start up - Starts up about 60% faster PR-URL: https://github.com/nodejs/node/pull/21405 Reviewed-By: John-David Dalton <john.david.dalton@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Gus Caplan <me@gus.host>
2018-06-18 19:02:57 +02:00
[ 'node_code_cache_path!=""', {
'sources': [ '<(node_code_cache_path)' ]
}, {
'sources': [ 'src/node_code_cache_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_shared=="true" and OS=="aix"', {
'product_name': 'node_base',
}],
[ 'v8_enable_inspector==1', {
'defines': [
'HAVE_INSPECTOR=1',
],
'sources': [
'src/inspector_agent.cc',
'src/inspector_io.cc',
'src/inspector_js_api.cc',
'src/inspector_socket.cc',
'src/inspector_socket_server.cc',
'src/inspector/main_thread_interface.cc',
'src/inspector/worker_inspector.cc',
'src/inspector/node_string.cc',
'src/inspector/worker_agent.cc',
'src/inspector/tracing_agent.cc',
'src/inspector_agent.h',
'src/inspector_io.h',
'src/inspector_socket.h',
'src/inspector_socket_server.h',
'src/inspector/main_thread_interface.h',
'src/inspector/worker_inspector.h',
'src/inspector/node_string.h',
'src/inspector/worker_agent.h',
'src/inspector/tracing_agent.h',
'<@(node_inspector_generated_sources)'
],
'dependencies': [
'node_protocol_generated_sources#host',
'v8_inspector_compress_protocol_json#host',
],
'include_dirs': [
'<(SHARED_INTERMEDIATE_DIR)/include', # for inspector
'<(SHARED_INTERMEDIATE_DIR)',
'<(SHARED_INTERMEDIATE_DIR)/src', # for inspector
],
}, {
'defines': [ 'HAVE_INSPECTOR=0' ]
}],
[ 'OS=="win"', {
'conditions': [
[ 'node_intermediate_lib_type!="static_library"', {
'sources': [
'src/res/node.rc',
],
}],
],
'libraries': [ '-lpsapi.lib' ]
}],
[ 'node_use_etw=="true"', {
'defines': [ 'HAVE_ETW=1' ],
'dependencies': [ 'node_etw' ],
'include_dirs': [
'src',
'tools/msvs/genfiles',
'<(SHARED_INTERMEDIATE_DIR)' # for node_natives.h
],
'sources': [
'src/node_win32_etw_provider.h',
'src/node_win32_etw_provider-inl.h',
'src/node_win32_etw_provider.cc',
'src/node_dtrace.cc',
'tools/msvs/genfiles/node_etw_provider.h',
],
'conditions': [
['node_intermediate_lib_type != "static_library"', {
'sources': [
'tools/msvs/genfiles/node_etw_provider.rc',
],
}],
],
}],
[ 'node_use_dtrace=="true"', {
'defines': [ 'HAVE_DTRACE=1' ],
'dependencies': [
'node_dtrace_header',
'specialize_node_d',
],
'include_dirs': [ '<(SHARED_INTERMEDIATE_DIR)' ],
#
# DTrace is supported on linux, solaris, mac, and bsd. There are
# three object files associated with DTrace support, but they're
# not all used all the time:
#
# node_dtrace.o all configurations
# node_dtrace_ustack.o not supported on mac and linux
# node_dtrace_provider.o All except OS X. "dtrace -G" is not
# used on OS X.
#
# Note that node_dtrace_provider.cc and node_dtrace_ustack.cc do not
# actually exist. They're listed here to trick GYP into linking the
# corresponding object files into the final "node" executable. These
# object files are generated by "dtrace -G" using custom actions
# below, and the GYP-generated Makefiles will properly build them when
# needed.
#
'sources': [ 'src/node_dtrace.cc' ],
'conditions': [
[ 'OS=="linux"', {
'sources': [
'<(SHARED_INTERMEDIATE_DIR)/node_dtrace_provider.o'
],
}],
[ 'OS!="mac" and OS!="linux"', {
'sources': [
'src/node_dtrace_ustack.cc',
'src/node_dtrace_provider.cc',
]
}
] ]
} ],
[ 'node_use_openssl=="true"', {
'sources': [
'src/node_crypto.cc',
'src/node_crypto_bio.cc',
'src/node_crypto_clienthello.cc',
'src/node_crypto.h',
'src/node_crypto_bio.h',
'src/node_crypto_clienthello.h',
'src/tls_wrap.cc',
'src/tls_wrap.h'
],
}],
],
2011-08-04 02:01:30 +02:00
},
{
'target_name': 'mkssldef',
'type': 'none',
# TODO(bnoordhuis) Make all platforms export the same list of symbols.
# Teach mkssldef.py to generate linker maps that UNIX linkers understand.
'conditions': [
[ 'use_openssl_def==1', {
'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,'
'FP_API,TLS1_METHOD,TLS1_1_METHOD,TLS1_2_METHOD,SCRYPT',
# 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_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'],
'action': [
'python',
'tools/mkssldef.py',
'<@(mkssldef_flags)',
'-o',
'<@(_outputs)',
'<@(_inputs)',
],
},
],
}],
],
},
# generate ETW header and resource files
{
'target_name': 'node_etw',
'type': 'none',
'conditions': [
[ 'node_use_etw=="true"', {
'actions': [
{
'action_name': 'node_etw',
'inputs': [ 'src/res/node_etw_provider.man' ],
'outputs': [
'tools/msvs/genfiles/node_etw_provider.rc',
'tools/msvs/genfiles/node_etw_provider.h',
'tools/msvs/genfiles/node_etw_providerTEMP.BIN',
],
'action': [ 'mc <@(_inputs) -h tools/msvs/genfiles -r tools/msvs/genfiles' ]
}
]
} ]
]
},
2011-08-04 02:01:30 +02:00
{
'target_name': 'node_js2c',
'type': 'none',
'toolsets': ['host'],
'actions': [
{
'action_name': 'node_js2c',
'process_outputs_as_sources': 1,
2011-08-04 02:01:30 +02:00
'inputs': [
'<@(library_files)',
'./config.gypi',
'tools/check_macros.py'
2011-08-04 02:01:30 +02:00
],
'outputs': [
'<(SHARED_INTERMEDIATE_DIR)/node_javascript.cc',
2011-08-04 02:01:30 +02:00
],
2011-08-05 01:40:07 +02:00
'conditions': [
[ 'node_use_dtrace=="false" and node_use_etw=="false"', {
'inputs': [ 'src/notrace_macros.py' ]
}],
[ 'node_debug_lib=="false"', {
'inputs': [ 'tools/nodcheck_macros.py' ]
}],
[ 'node_debug_lib=="true"', {
'inputs': [ 'tools/dcheck_macros.py' ]
}]
],
'action': [
'python',
'tools/js2c.py',
'<@(_outputs)',
'<@(_inputs)',
],
2011-08-04 02:01:30 +02:00
},
],
}, # end node_js2c
{
'target_name': 'node_dtrace_header',
'type': 'none',
'conditions': [
[ 'node_use_dtrace=="true" and OS!="linux"', {
'actions': [
{
'action_name': 'node_dtrace_header',
'inputs': [ 'src/node_provider.d' ],
'outputs': [ '<(SHARED_INTERMEDIATE_DIR)/node_provider.h' ],
'action': [ 'dtrace', '-h', '-xnolibs', '-s', '<@(_inputs)',
'-o', '<@(_outputs)' ]
}
]
} ],
[ 'node_use_dtrace=="true" and OS=="linux"', {
'actions': [
{
'action_name': 'node_dtrace_header',
'inputs': [ 'src/node_provider.d' ],
'outputs': [ '<(SHARED_INTERMEDIATE_DIR)/node_provider.h' ],
'action': [ 'dtrace', '-h', '-s', '<@(_inputs)',
'-o', '<@(_outputs)' ]
}
]
} ],
]
},
{
'target_name': 'node_dtrace_provider',
'type': 'none',
'conditions': [
[ 'node_use_dtrace=="true" and OS!="mac" and OS!="linux"', {
'actions': [
{
'action_name': 'node_dtrace_provider_o',
'inputs': [
'<(obj_dir)/<(node_lib_target_name)/src/node_dtrace.o',
],
'outputs': [
'<(obj_dir)/<(node_lib_target_name)/src/node_dtrace_provider.o'
],
2013-04-17 01:18:07 +02:00
'action': [ 'dtrace', '-G', '-xnolibs', '-s', 'src/node_provider.d',
'<@(_inputs)', '-o', '<@(_outputs)' ]
}
]
}],
[ 'node_use_dtrace=="true" and OS=="linux"', {
'actions': [
{
'action_name': 'node_dtrace_provider_o',
'inputs': [ 'src/node_provider.d' ],
'outputs': [
'<(SHARED_INTERMEDIATE_DIR)/node_dtrace_provider.o'
],
'action': [
'dtrace', '-C', '-G', '-s', '<@(_inputs)', '-o', '<@(_outputs)'
],
}
],
}],
]
},
{
'target_name': 'node_dtrace_ustack',
'type': 'none',
'conditions': [
[ 'node_use_dtrace=="true" and OS!="mac" and OS!="linux"', {
'actions': [
{
'action_name': 'node_dtrace_ustack_constants',
'inputs': [
'<(v8_base)'
],
'outputs': [
'<(SHARED_INTERMEDIATE_DIR)/v8constants.h'
],
'action': [
'tools/genv8constants.py',
'<@(_outputs)',
'<@(_inputs)'
]
},
{
'action_name': 'node_dtrace_ustack',
'inputs': [
'src/v8ustack.d',
'<(SHARED_INTERMEDIATE_DIR)/v8constants.h'
],
'outputs': [
'<(obj_dir)/<(node_lib_target_name)/src/node_dtrace_ustack.o'
],
'conditions': [
[ 'target_arch=="ia32" or target_arch=="arm"', {
'action': [
'dtrace', '-32', '-I<(SHARED_INTERMEDIATE_DIR)', '-Isrc',
'-C', '-G', '-s', 'src/v8ustack.d', '-o', '<@(_outputs)',
]
} ],
[ 'target_arch=="x64"', {
'action': [
'dtrace', '-64', '-I<(SHARED_INTERMEDIATE_DIR)', '-Isrc',
'-C', '-G', '-s', 'src/v8ustack.d', '-o', '<@(_outputs)',
]
} ],
]
},
]
} ],
]
},
{
'target_name': 'specialize_node_d',
'type': 'none',
'conditions': [
[ 'node_use_dtrace=="true"', {
'actions': [
{
'action_name': 'specialize_node_d',
'inputs': [
'src/node.d'
],
'outputs': [
'<(PRODUCT_DIR)/node.d',
],
'action': [
'tools/specialize_node_d.py',
'<@(_outputs)',
'<@(_inputs)',
'<@(OS)',
'<@(target_arch)',
],
},
],
} ],
]
},
{
# When using shared lib to build executable in Windows, in order to avoid
# filename collision, the executable name is node-win.exe. Need to rename
# it back to node.exe
'target_name': 'rename_node_bin_win',
'type': 'none',
'dependencies': [
'<(node_core_target_name)',
],
'conditions': [
[ 'OS=="win" and node_intermediate_lib_type=="shared_library"', {
'actions': [
{
'action_name': 'rename_node_bin_win',
'inputs': [
'<(PRODUCT_DIR)/<(node_core_target_name)-win.exe'
],
'outputs': [
'<(PRODUCT_DIR)/<(node_core_target_name).exe',
],
'action': [
'mv', '<@(_inputs)', '<@(_outputs)',
],
},
],
} ],
]
},
{
'target_name': 'cctest',
'type': 'executable',
'dependencies': [
'<(node_lib_target_name)',
'rename_node_bin_win',
'deps/gtest/gtest.gyp:gtest',
'node_js2c#host',
'node_dtrace_header',
'node_dtrace_ustack',
'node_dtrace_provider',
],
'includes': [
'node.gypi'
],
'include_dirs': [
'src',
'tools/msvs/genfiles',
'deps/v8/include',
'deps/cares/include',
'deps/uv/include',
'<(SHARED_INTERMEDIATE_DIR)', # for node_natives.h
],
'defines': [ 'NODE_WANT_INTERNALS=1' ],
'sources': [
'test/cctest/node_test_fixture.cc',
'test/cctest/test_aliased_buffer.cc',
'test/cctest/test_base64.cc',
'test/cctest/test_node_postmortem_metadata.cc',
'test/cctest/test_environment.cc',
'test/cctest/test_platform.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',
],
}],
['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',
}],
],
}
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 16:22:00 +02:00
], # end targets
'conditions': [
[ 'OS=="aix" and node_shared=="true"', {
'variables': {'real_os_name': '<!(uname -s)',},
'targets': [
{
'target_name': 'node_aix_shared',
'type': 'shared_library',
'product_name': '<(node_core_target_name)',
'ldflags': [ '--shared' ],
'product_extension': '<(shlib_suffix)',
'conditions': [
['target_arch=="ppc64"', {
'ldflags': [
'-Wl,-blibpath:/usr/lib:/lib:'
'/opt/freeware/lib/pthread/ppc64'
],
}],
['target_arch=="ppc"', {
'ldflags': [
'-Wl,-blibpath:/usr/lib:/lib:/opt/freeware/lib/pthread'
],
}],
['"<(real_os_name)"=="OS400"', {
'ldflags': [
'-Wl,-blibpath:/QOpenSys/pkgs/lib:/QOpenSys/usr/lib',
'-Wl,-bbigtoc',
'-Wl,-brtl',
],
}],
],
'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 16:22:00 +02:00
'include_dirs': [
'src',
'deps/v8/include',
],
'sources': [
'<@(library_files)',
'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 16:22:00 +02: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 16:22:00 +02:00
}], # end aix section
[ 'v8_enable_inspector==1', {
'variables': {
'protocol_path': 'tools/inspector_protocol',
'node_inspector_path': 'src/inspector',
'node_inspector_generated_sources': [
'<(SHARED_INTERMEDIATE_DIR)/src/node/inspector/protocol/Forward.h',
'<(SHARED_INTERMEDIATE_DIR)/src/node/inspector/protocol/Protocol.cpp',
'<(SHARED_INTERMEDIATE_DIR)/src/node/inspector/protocol/Protocol.h',
'<(SHARED_INTERMEDIATE_DIR)/src/node/inspector/protocol/NodeWorker.cpp',
'<(SHARED_INTERMEDIATE_DIR)/src/node/inspector/protocol/NodeWorker.h',
'<(SHARED_INTERMEDIATE_DIR)/src/node/inspector/protocol/NodeTracing.cpp',
'<(SHARED_INTERMEDIATE_DIR)/src/node/inspector/protocol/NodeTracing.h',
],
'node_protocol_files': [
'<(protocol_path)/lib/Allocator_h.template',
'<(protocol_path)/lib/Array_h.template',
'<(protocol_path)/lib/Collections_h.template',
'<(protocol_path)/lib/DispatcherBase_cpp.template',
'<(protocol_path)/lib/DispatcherBase_h.template',
'<(protocol_path)/lib/ErrorSupport_cpp.template',
'<(protocol_path)/lib/ErrorSupport_h.template',
'<(protocol_path)/lib/Forward_h.template',
'<(protocol_path)/lib/FrontendChannel_h.template',
'<(protocol_path)/lib/Maybe_h.template',
'<(protocol_path)/lib/Object_cpp.template',
'<(protocol_path)/lib/Object_h.template',
'<(protocol_path)/lib/Parser_cpp.template',
'<(protocol_path)/lib/Parser_h.template',
'<(protocol_path)/lib/Protocol_cpp.template',
'<(protocol_path)/lib/ValueConversions_h.template',
'<(protocol_path)/lib/Values_cpp.template',
'<(protocol_path)/lib/Values_h.template',
'<(protocol_path)/templates/Exported_h.template',
'<(protocol_path)/templates/Imported_h.template',
'<(protocol_path)/templates/TypeBuilder_cpp.template',
'<(protocol_path)/templates/TypeBuilder_h.template',
'<(protocol_path)/CodeGenerator.py',
]
},
'targets': [
{
'target_name': 'prepare_protocol_json',
'type': 'none',
'toolsets': ['host'],
'copies': [
{
'files': [
'<(node_inspector_path)/node_protocol_config.json',
'<(node_inspector_path)/node_protocol.pdl'
],
'destination': '<(SHARED_INTERMEDIATE_DIR)',
}
],
'actions': [
{
'action_name': 'convert_node_protocol_to_json',
'inputs': [
'<(SHARED_INTERMEDIATE_DIR)/node_protocol.pdl',
],
'outputs': [
'<(SHARED_INTERMEDIATE_DIR)/node_protocol.json',
],
'action': [
'python',
'tools/inspector_protocol/ConvertProtocolToJSON.py',
'<@(_inputs)',
'<@(_outputs)',
],
},
]
},
{
'target_name': 'node_protocol_generated_sources',
'type': 'none',
'toolsets': ['host'],
'dependencies': ['prepare_protocol_json'],
'actions': [
{
'action_name': 'node_protocol_generated_sources',
'inputs': [
'<(SHARED_INTERMEDIATE_DIR)/node_protocol_config.json',
'<(SHARED_INTERMEDIATE_DIR)/node_protocol.json',
'<@(node_protocol_files)',
],
'outputs': [
'<@(node_inspector_generated_sources)',
],
'action': [
'python',
'<(protocol_path)/CodeGenerator.py',
'--jinja_dir', '<@(protocol_path)/..',
'--output_base', '<(SHARED_INTERMEDIATE_DIR)/src/',
'--config', '<(SHARED_INTERMEDIATE_DIR)/node_protocol_config.json',
],
'message': 'Generating node protocol sources from protocol json',
},
]
},
{
'target_name': 'v8_inspector_compress_protocol_json',
'type': 'none',
'toolsets': ['host'],
'copies': [
{
'destination': '<(SHARED_INTERMEDIATE_DIR)',
'files': ['deps/v8/src/inspector/js_protocol.pdl']
}
],
'actions': [
{
'action_name': 'v8_inspector_convert_protocol_to_json',
'inputs': [
'<(SHARED_INTERMEDIATE_DIR)/js_protocol.pdl',
],
'outputs': [
'<(SHARED_INTERMEDIATE_DIR)/js_protocol.json',
],
'action': [
'python',
'tools/inspector_protocol/ConvertProtocolToJSON.py',
'<@(_inputs)',
'<@(_outputs)',
],
},
{
'action_name': 'concatenate_protocols',
'inputs': [
'<(SHARED_INTERMEDIATE_DIR)/js_protocol.json',
'<(SHARED_INTERMEDIATE_DIR)/node_protocol.json',
],
'outputs': [
'<(SHARED_INTERMEDIATE_DIR)/concatenated_protocol.json',
],
'action': [
'python',
'tools/inspector_protocol/ConcatenateProtocols.py',
'<@(_inputs)',
'<@(_outputs)',
],
},
{
'action_name': 'v8_inspector_compress_protocol_json',
'process_outputs_as_sources': 1,
'inputs': [
'<(SHARED_INTERMEDIATE_DIR)/concatenated_protocol.json',
],
'outputs': [
'<(SHARED_INTERMEDIATE_DIR)/v8_inspector_protocol_json.h',
],
'action': [
'python',
'tools/compress_json.py',
'<@(_inputs)',
'<@(_outputs)',
],
},
],
},
]
}]
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 16:22:00 +02:00
], # end conditions block
2011-08-04 02:01:30 +02:00
}