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.
Header files for deps are in a different location in the Node.js
source tree compared to the release tarballs.
PR-URL: https://github.com/nodejs/node-gyp/pull/1055
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Initial work to add z/OS support to node-gyp.
PR-URL: https://github.com/nodejs/node-gyp/pull/1276
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Set path to node lib in `$(Configuration)` dir when `--nodedir` option
is supplied, otherwise use value of `target_arch` variable.
PR-URL: https://github.com/nodejs/node-gyp/pull/964
Reviewed-By: João Reis <reis@janeasystems.com>
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>
Microsoft's chakracore engine is dependent on Windows SDK, and build
tools should know the version installed on user machine. This change
adds those dependencies in node-gyp tools. Below is the summary:
* Configure msvs_windows_target_platform_version to use the right
Windows SDK.
* Configure msvs_use_library_dependency_inputs to export symbols
correctly (otherwise functions not used by node.exe but might be
needed by native addon modules could be optimized away by linker).
These changes were originally made in nodejs/node#4765, but as @shigeki
mentioned, it was more sensible to send these changes as PR to node-gyp
repo.
PR-URL: https://github.com/nodejs/node-gyp/pull/873
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
We were inheriting BUILDING_UV_SHARED and BUILDING_V8_SHARED from
the common.gypi from the node.js source tree. Override them with
USING_UV_SHARED and USING_V8_SHARED so symbols get tagged with
`__declspec(dllimport)` instead of `__declspec(dllexport)`, which
is the desired attribute when building add-ons.
Fixes: https://github.com/nodejs/node-gyp/issues/914
PR-URL: https://github.com/nodejs/node-gyp/pull/915
Reviewed-By: Benjamin Byholm <bbyholm@abo.fi>
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Visual Studio 2015 Update 3 defines __pfnDliNotifyHook2 as const.
The decltype specifier makes the declaration work across all supported
versions of VS. It also requires that the source be compiled as C++.
Fixes: https://github.com/nodejs/node-gyp/issues/949
PR-URL: https://github.com/nodejs/node-gyp/pull/952
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
It will be helpful for native module developers to be aware of any
deprecated apis they are using so that they can update before their
modules break completely. Module developers can override this option
in their binding.gyp if they do not want to see these warnings.
PR-URL: https://github.com/nodejs/node-gyp/pull/920
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>
Adding "-undefined dynamic_lookup" to all targets makes it impossible to create Xcode projects with node-gyp for gyp files that also include "none" targets. Since non-targets don't have a framework phase, gyp errors when trying to add the link flag.
In addition, "-undefined dynamic_lookup" should be added as a linker flag, not a link library, so it's now passed in the "OTHER_LDFLAGS" setting
On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This causes many compiled addons to break when node.exe or iojs.exe are
renamed, because when the binary has been renamed the addon DLL can't
find the (right) .exe file to load its imports from.
This patch gives compiled addon developers an option to overcome this
restriction by compiling a delay-load hook into their binary. The
delay-load hook ensures that whenever a module tries to load imports
from node.exe/iojs.exe, it'll just look at the process image, thereby
making the addon work regardless of what name the node/iojs binary has.
To enable this feature, the addon developer must set the
'win_delay_load_hook' option to 'true' in their binding.gyp file, like
this:
```
{
'targets': [
{
'target_name': 'ernie',
'win_delay_load_hook': 'true',
...
```
Bug: https://github.com/iojs/io.js/issues/751
Bug: https://github.com/iojs/io.js/issues/965
Use quotation marks to encapsulate the path to node.lib.
Use ConfigurationName instead of Configuration for the
variable getting the Debug/Release directory.
Older linkers don't have the -T flag.
This is a somewhat experimental feature, so if user's want "thin"
archives, they can specify `--thin` to revert to the original behavior.
This seems more appropriate for how node native addons are build, such that
you don't actually know where the addon will reside when installed. Before,
addons would get "/usr/local/lib/binding.node" hard-coded into their load-path
and that is just plain wrong.
Still need to look into if this is necessary for other Unix platforms than OS X.
This way, when a native module depends on a static library through gyp, then
it will have the platform-appropriate suffix (i.e. ".a" or ".lib").
Same goes for "shared_library" types and others as well.
