NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
70,040 Commits 5 Branches 387 Tags 141 MiB
Makefile 64%
Python 15.3%
C 9.2%
Shell 6%
PHP 2.8%
Other 2.4%
359eb5072d
Go to file
Giulio Benetti 359eb5072d package/nodejs: fix build of modules with native code 
When installing node modules with native code, said code needs to be
built for the target; npm will delegate that to an internal copy of gyp,
node_gyp, which uses a python script to generate the build configuration
matching the target.

That script is generated by the nodejs build system (at configure time),
and eventually installed to staging alongside the headers.

Currently, we tell node_gyp to use the script in the nodejs build
directory, with the npm_config_nodedir environment variable:
    npm_config_nodedir=$(BUILD_DIR)/nodejs-$(NODEJS_VERSION)

However, that is no longer working since commit 4cbc2af604
(package/nodejs: rename to nodejs-src and convert to virtual package),
for two reasons:

  - the version variable NODEJS_VERSION was renamed to
    NODEJS_COMMON_VERSION;

  - the actual build directory is that of nodejs-src, not nodejs.

When installing node modules with NODEJS_SRC_MODULES_LIST, we happen to
still be running in the nodejs-src package, so it kinda makes sense that
we use the file in nodejs-src build directory. But the NPM macro can
also be called from other packages, in which case it looks uglier to
have to look into nosejs-src build dir from another package context.

Looking at the documentation for node-gyp [0], we can see that nodedir
is meant to point to the path of the node source code;

    | `--nodedir=$path`                 | Set the path to the node source code

However, that is only valid when building natively; here we are more
similar to the "Third Party Node.js Runtimes", where the runtime nodejs
is not the one doing the build; in that case, the following looks more
appropriate:

    [...] you
    should use `--dist-url` or `--nodedir` flags to specify the headers of the
    runtime to build for.

    Also when `--dist-url` or `--nodedir` flags are passed, node-gyp will use the
    `config.gypi` shipped in the headers distribution to generate build
    configurations [...]

So, we are going that route, and point npm_config_nodedir to the staging
dir, where the headers are to be found. This is valid when installing
modules with NODEJS_SRC_MODULES_LIST, as nodejs is already installed in
staging at that time, as the package infra guarantees that staging is
installed before target; it alsop works for modules installed in later
packages (as long as they have nodejs in their dependencies, of course).

Fixes: https://bugs.busybox.net/show_bug.cgi?id=15826

[0] https://github.com/nodejs/node/blob/main/deps/npm/node_modules/node-gyp/README.md

Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[yann.morin.1998@free.fr:
  - use STAGING_DIR/usr, not TARGET_DIR/usr
  - extend commit log to explain what and why
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2023-11-07 22:34:57 +01:00
arch arch/powerpc: drop ABI selection 2023-08-20 23:22:27 +02:00
board configs/avenger96_defconfig: downgrade to TF-A v2.5 2023-11-06 23:10:39 +01:00
boot boot/arm-trusted-firmware: set BUILD_STRING to package version 2023-11-02 14:43:57 +01:00
configs configs/avenger96_defconfig: downgrade to TF-A v2.5 2023-11-06 23:10:39 +01:00
docs package/pkg-download: lookup hash files in global-patch-dir 2023-11-07 11:48:46 +01:00
fs fs/cpio: allow users to provide their own dracut modules 2023-02-06 22:46:35 +01:00
linux {linux, linux-headers}: bump 6.{1, 5}.x series 2023-11-03 23:14:30 +01:00
package package/nodejs: fix build of modules with native code 2023-11-07 22:34:57 +01:00
support support/download: teach dl-wrapper to handle more than one hash file 2023-11-07 11:48:45 +01:00
system package/petitboot: run petitboot UI on consoles 2023-11-05 19:04:41 +01:00
toolchain {toolchain, linux-headers}: add support for 6.6 headers 2023-11-01 19:22:47 +01:00
utils utils/docker-run: propagate user's proxy settings 2023-11-04 18:42:48 +01:00
.checkpackageignore package/python-dnspython: bump to version 2.4.2 2023-11-06 23:15:25 +01:00
.clang-format
.defconfig
.editorconfig .editorconfig: add editor-agnostic configuration 2023-11-01 22:53:16 +01:00
.flake8
.gitignore
.gitlab-ci.yml support/misc/gitlab-ci.yml.in: retry a job only if it failed due to a runner issue 2023-08-27 10:09:37 +02:00
.shellcheckrc utils/check-package: improve shellcheck reproducibility 2022-07-25 23:52:47 +02:00
CHANGES Update for 2023.02.6 2023-10-16 11:46:01 +02:00
Config.in pkg-download: add option to enforce hash checking 2023-11-07 11:48:46 +01:00
Config.in.legacy package/openjdk{-bin}: drop OpenJDK11 and add OpenJDK21 2023-11-01 19:00:50 +01:00
COPYING
DEVELOPERS support/testing/tests/package/test_firewalld.py: new test 2023-11-06 20:43:55 +01:00
Makefile support/download: teach dl-wrapper to handle more than one hash file 2023-11-07 11:48:45 +01:00
Makefile.legacy
README

README 

Buildroot is a simple, efficient and easy-to-use tool to generate embedded
Linux systems through cross-compilation.

The documentation can be found in docs/manual. You can generate a text
document with 'make manual-text' and read output/docs/manual/manual.text.
Online documentation can be found at http://buildroot.org/docs.html

To build and use the buildroot stuff, do the following:

1) run 'make menuconfig'
2) select the target architecture and the packages you wish to compile
3) run 'make'
4) wait while it compiles
5) find the kernel, bootloader, root filesystem, etc. in output/images

You do not need to be root to build or run buildroot.  Have fun!

Buildroot comes with a basic configuration for a number of boards. Run
'make list-defconfigs' to view the list of provided configurations.

Please feed suggestions, bug reports, insults, and bribes back to the
buildroot mailing list: buildroot@buildroot.org
You can also find us on #buildroot on OFTC IRC.

If you would like to contribute patches, please read
https://buildroot.org/manual.html#submitting-patches