BREAKING CHANGE: All internal functions have been coverted to return
promises and no longer accept callbacks. This is not a breaking change
for users but may be breaking to consumers of `node-gyp` if you are
requiring internal functions directly.
* fix: create Python symlink only during builds, and clean it up after
Previously in b9ddcd5bbd this was created
during configuration, and the symlink persisted indefinitely. This
causes problems with many tools that do not expect a codebase to include
symlinks to external absolute paths.
This PR largely reverts that commit, and instead writes the path to
link to into the config, and then creates the symlink only temporarily
during the build process, always deleting it afterwards.
* assert install_path == self.output, f"{install_path} != {self.output}"
---------
Co-authored-by: Christian Clauss <cclauss@me.com>
Python 3.9 on IBM i now properly returns "os400" for sys.platform
instead of claiming to be AIX as it did previously. While the IBM i PASE
environment is compatible with AIX, it is a subset and has numerous
differences which makes it beneficial to distinguish, however this means
that it now needs explicit support here.
* lib: create a Python symlink and add it to PATH
Helps to ensure a version of Python validated by lib/find-python.js
is used to run various Python scripts generated by gyp.
Known to affect gyp-mac-tool, probably affects gyp-flock-tool as well.
These Python scripts (such as `gyp-mac-tool`) are invoked directly,
via the generated Makefile, so their shebang lines determine
which Python binary is used to run them.
The shebang lines of these scripts are all `#!/usr/bin/env python3`,
so the first `python3` on the user's PATH will be used.
By adding a symlink to the Python binary validated by find-python.js,
and putting this symlink first on the PATH, we can ensure we use
a compatible version of Python to run these scripts.
(Only on Unix/Unix-like OSes. Symlinks are tricky on Windows,
and Python isn't used at build-time anyhow on Windows,
so this intervention isn't useful or necessary on Windows.
A similar technique for Windows, no symlinks required,
would be to make batch scripts which execute the target binary,
much like what Node does for its bundled copy of npm on Windows.)
* test: update mocked graceful-fs for configure test
Add missing functions "unlink()" and "symlink()" to mocked module.
* lib: log any errors when creating Python symlink
Warn users about errors, but continue on in case the user does
happen to have new enough Python on their PATH.
(The symlinks are only meant to fix an issue in a corner case,
where the user told `node-gyp` where new enough Python is,
but it's not the first `python3` on their PATH.
We should not introduce a new potential failure mode to all users
when fixing this bug. So no hard errors during the symlink process.)
* lib: improve error formatting for Python symlink
Logging the entire error object shows the stack twice,
and all the other information is contained in the stack.
It also messes with the order of what is logged.
Rather than logging a bunch of redundant information in a messy way,
we can log only the stack. Logging it in a separate log.warn()
also gets rid of an extra space character at the beginning of the line.
* lib: restore err.errno to logs for symlink errors
This info (err.errno) is the only piece of information
in the error object that is not redundant to err.stack.
* lib: use log.verbose, not log.warn
These messages aren't important enough to be `log.warn`s.
Log as verbose only; they will also appear in full error output.
In addition:
* moved module.exports to the bottom
* no single-line if statements
* no if statements without a {
* const for requires
* array declarations get spaces inside [ ]
* 'use strict' in all .js files
PR-URL: https://github.com/nodejs/node-gyp/pull/1794
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: João Reis <reis@janeasystems.com>
- Uses `.eslintrc.yaml` for configuration
- `npm run lint` is part of `npm test`
PR-URL: https://github.com/nodejs/node-gyp/pull/1497
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: João Reis <reis@janeasystems.com>
- Removes "module dependencies" comments and things that, IMHO, don't add
too much value. Happy to add back if helps some people when reading
through `node-gyp`.
- DRY up `lib/process-release.js`.
- Removes a bunch of extra blank lines, as well as random spaces.
PR-URL: https://github.com/nodejs/node-gyp/pull/1508
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Currently, on non-Windows platforms, it is possible to have
a multi-target native module and specify building just some
of the targets using `node-gyp build my_target`.
On Windows, however, specifying the targets to build requires the `/t:`
or `/target:` flag. Without this change you will get an `MSB1008` error
because MSBuild thinks you are trying to specify multiple solutions.
PR-URL: https://github.com/nodejs/node-gyp/pull/1164
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Using `target_arch` in addon.gypi to link against Node.js library. This
variable was written into build/config.gypi on the `configure` stage.
Do not copy node.lib into node_root_dir/Release or node_root_dir/Debug
on Windows, link it from node_root_dir/target_arch directory.
PR-URL: https://github.com/nodejs/node-gyp/pull/964
Reviewed-By: João Reis <reis@janeasystems.com>
PR-URL: https://github.com/nodejs/node-gyp/pull/1130
Reviewed-By: João Reis <reis@janeasystems.com>
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Rod Vagg <rod@vagg.org>
* Support building node.js with chakracore on Windows on ARM
* Building chakracore for ARM has a dependency on Windows SDK installed
on the machine. Update python script to populate
`WindowsSDKDesktopARMSupport` and `WindowsTargetPlatformVersion` for
ARM builds. This will be using in node repo to build`chakracore.gyp`.
PR-URL: https://github.com/nodejs/node-gyp/pull/873
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
For AIX we need to use gmake.
For AIX we need to set up the path to the exp file which contains the
symbols needed for linking. The file will either be in one of the
following depeding on whether are are in installed or development
environment:
- the include/node directory
- the out/Release directory
PR-URL: https://github.com/nodejs/node-gyp/pull/753
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
This platform value came from debian package, and now the value
from debian package is simply "freebsd", so this check is useless.
PR-URL: https://github.com/nodejs/node-gyp/pull/738
Reviewed-By: rvagg
Reviewed-By: bnoordhuis
Reviewed-By: jbergstroem
If you use the environment variable `JOBS` which are set '0' for other purpose,
`node-gpy rebuild` will fail to execute `make`.
Because the `-j` option of `make` require a non-zero positive integer.
Here is a simple repro:
```
$ JOBS=0 npm install nightmare
...
> weak@0.3.3 install /home/kui/tmp/nm/node_modules/nightmare/node_modules/phantom/node_modules/dnode/node_modules/weak
> node-gyp rebuild
make: the `-j' option requires a positive integral argument
Usage: make [options] [target] ...
Options:
-b, -m Ignored for compatibility.
-B, --always-make Unconditionally make all targets.
-C DIRECTORY, --directory=DIRECTORY
Change to DIRECTORY before doing anything.
-d Print lots of debugging information.
..
```
