This makes compiling v8_base much faster on Windows.
Sharding is disabled because the header would have to be precompiled
for each shard but is only once. The library is much smaller, so
sharding is unnecessary.
This is enabled by default, but disabled for CI and releases.
PR-URL: https://github.com/nodejs/node/pull/21772
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Kyle Farnung <kfarnung@microsoft.com>
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Instead of requiring `./configure` to be run again after
the file changed, first try to re-run the configure script
with the arguments with which it was originally run.
Usually, those arguments will either contain no flags,
or all flags that were passed are still supported.
PR-URL: https://github.com/nodejs/node/pull/21371
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
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>
Using High Sierra and `xcode-select --install` without installing full
Xcode, our build tooling breaks due to faulty regular expressions.
Update the `configure` script in our project root directory to handle
multi-digit version numbers.
`tools/gyp` and `deps/npm/node_modules/node-gyp` still need to be
updated for a complete fix.
PR-URL: https://github.com/nodejs/node/pull/21173
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Some GNU assembler versions got localized outputs like...
```
Gnu assembler versão 2.30 (x86_64-linux-gnu) usando versão BFD (GNU Binutils for Ubuntu) 2.30
```
failing regex checker and the whole configure process.
PR-URL: https://github.com/nodejs/node/pull/20394
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
Remove `--debug-http2` as a compile-time feature and
make all debug statements available using `NODE_DEBUG_NATIVE=http2`
at runtime.
This probably makes the debugging-enabled case a bit slower due to
additional string concatenations, but switching to a runtime-checking
system makes debugging more flexible and can be applied more easily
to other parts of the source code as well.
PR-URL: https://github.com/nodejs/node/pull/20987
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Minwoo Jung <minwoo@nodesource.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Currently when configuring --without-ssl the following warning is
displayed:
WARNING: openssl_no_asm is enabled due to missed or old assembler.
Please refer BUILDING.md
This commit adds a check of options.without_ssl to avoid this warning
when --without-ssl is used.
PR-URL: https://github.com/nodejs/node/pull/19934
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
- For Windows, nasm is new build requirements and openssl_no_asm is
set to 1 with warning if it is not installed.
- For use of openssl assemble codes, either gas_version >= 2.23,
xcode_version >= 5.0 ,llvm_version >= 3.3 or nasm_version >= 2.10 is
needed. Otherwise, openssl_no_asm is set to 1 with warning.
- FIPS is not supported in OpenSSL-1.1.0 so that it leads an error
when openssl_fips options is enabled in configure.
Fixes: https://github.com/nodejs/node/issues/4270
PR-URL: https://github.com/nodejs/node/pull/19794
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rod Vagg <rod@vagg.org>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
The version of nghttp2 in deps/ does not build on CloudABI, even though
the official version does. Though this is an issue on its own that needs
to be resolved, it is currently a bit hard to work around this. There is
no switch to link against an external version of nghttp2, even though we
do provide this option for other libraries.
This change adds configure flags, similar to the ones we have for
OpenSSL, zlib, http_parser, libuv, etc. and makes the dependency on
deps/nghttp2 optional.
PR-URL: https://github.com/nodejs/node/pull/16788
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Refael Ackermann <refack@gmail.com>
The motivation for this commit is that we need to specify system CA
certificates when building node. While we are aware of the environment
variable NODE_EXTRA_CA_CERTS this is not a great solution as we build
an RPM and we also don't want users to be able to unset them.
The suggestion is to add a configure time property like this:
--openssl-system-ca-path=OPENSSL_SYSTEM_CA_PATH
Use the specified path to system CA (PEM format) in
addition to the OpenSSL supplied CA store or compiled-
in Mozilla CA copy.
Usage example:
$ ./configure --openssl-system-ca-path=/etc/pki/tls/certs/ca-bundle.crt
This would add the specified CA certificates in addition to the ones
already being used.
PR-URL: https://github.com/nodejs/node/pull/16790
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
CloudABI is a compact POSIX-like runtime that makes use of
capability-based security. More details:
https://github.com/NuxiNL/cloudlibc
* src: Disable use of pwd.h, grp.h and get*uid() on CloudABI.
As CloudABI is intended to run applications in cluster contexts (e.g.,
on Kubernetes), they are oblivious of UNIX credentials. Extend the
existing preprocessor checks to disable any use of these interfaces,
just like on Windows, Android, etc.
* src: Explicitly include <netdb.h>.
cares_wrap.cc calls into functions like getnameinfo() and getaddrinfo().
These functions tend to be available implicitly through <uv.h>, but we'd
better still include this header explicitly.
On CloudABI, we make use of a custom implementation of libuv that does
not implicitly include header files like <netdb.h>.
PR-URL: https://github.com/nodejs/node/pull/16612
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Currently the help message when using --with-lttng looks like this:
$ ./configure --help | grep 'with-lttng'
--with-lttng build with Lttng (Only available to Linux)
This commit makes the help message consistent with the error message
that is raised if --with-lttng is used on a non-Linux operating
system:
$ ./configure --help | grep 'with-lttng'
--with-lttng build with Lttng (Only available on Linux)
PR-URL: https://github.com/nodejs/node/pull/16101
Reviewed-By: Lance Ball <lball@redhat.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Currently the options available for HTTP2 are not displayed when running
configure --help.
This commit enables the following HTTP2 section to be included in the
help output:
HTTP2:
Flags that allows you to control HTTP2 features in Node.js
--debug-http2 build with http2 debug statements on (default is
false)
--debug-nghttp2 build nghttp2 with DEBUGBUILD (default is false)
PR-URL: https://github.com/nodejs/node/pull/15198
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Currently when building with --enable-static and running the test target
the following error will be reported:
Building addon
/node/test/addons/01_function_arguments/
env: ./node: No such file or directory
make[1]: *** [test/addons/.buildstamp] Error 1
Note that this is with a clean build where no prior node executable was
built.
This commit suggests only running the cctest target when --enable-static
is specified.
PR-URL: https://github.com/nodejs/node/pull/14892
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Lance Ball <lball@redhat.com>
Improve support for systems where `python` is actually `python3`.
Not all systems have a `python2` binary, so simply updating the shebang
won't work.
What we can do is apply some cleverness: start life as a shell script,
locate the python binary, then re-execute the script but this time as
python code.
Special care is taken to ensure that spaces in arguments are passed on
verbatim.
PR-URL: https://github.com/nodejs/node/pull/14737
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
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>
The ability to set the link rule is used for FIPS, and needs to set
both the `ld =` and `ldxx =` variables in the ninja build file to link
c++ (node) and c (openssl-cli, etc.) executables.
URL: https://github.com/nodejs/node/pull/14227
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
