Giter Club home page Giter Club logo

node-build's Introduction

Seamlessly manage your app’s Node environment with nodenv.

Use nodenv to pick a Node version for your application and guarantee that your development environment matches production. Put nodenv to work with npm for painless Node upgrades and bulletproof deployments.

Powerful in development. Specify your app's Node version once, in a single file. Keep all your teammates on the same page. No headaches running apps on different versions of Node. Just Works™ from the command line. Override the Node version anytime: just set an environment variable.

Rock-solid in production. Your application's executables are its interface with ops. With nodenv and you'll never again need to cd in a cron job or Chef recipe to ensure you've selected the right runtime. The Node version dependency lives in one place—your app—so upgrades and rollbacks are atomic, even when you switch versions.

One thing well. nodenv is concerned solely with switching Node versions. It's simple and predictable. A rich plugin ecosystem lets you tailor it to suit your needs. Compile your own Node versions, or use the node-build plugin to automate the process. Specify per-application environment variables with nodenv-vars. See more plugins on the wiki.

Why choose nodenv?

Table of Contents

How It Works

At a high level, nodenv intercepts Node commands using shim executables injected into your PATH, determines which Node version has been specified by your application, and passes your commands along to the correct Node installation.

Understanding PATH

When you run a command like node or npm, your operating system searches through a list of directories to find an executable file with that name. This list of directories lives in an environment variable called PATH, with each directory in the list separated by a colon:

/usr/local/bin:/usr/bin:/bin

Directories in PATH are searched from left to right, so a matching executable in a directory at the beginning of the list takes precedence over another one at the end. In this example, the /usr/local/bin directory will be searched first, then /usr/bin, then /bin.

Understanding Shims

nodenv works by inserting a directory of shims at the front of your PATH:

~/.nodenv/shims:/usr/local/bin:/usr/bin:/bin

Through a process called rehashing, nodenv maintains shims in that directory to match every Node command across every installed version of Node—node, npm, and so on.

Shims are lightweight executables that simply pass your command along to nodenv. So with nodenv installed, when you run, say, npm, your operating system will do the following:

  • Search your PATH for an executable file named npm
  • Find the nodenv shim named npm at the beginning of your PATH
  • Run the shim named npm, which in turn passes the command along to nodenv

Choosing the Node Version

When you execute a shim, nodenv determines which Node version to use by reading it from the following sources, in this order:

  1. The NODENV_VERSION environment variable, if specified. You can use the nodenv shell command to set this environment variable in your current shell session.

  2. The first .node-version file found by searching the directory of the script you are executing and each of its parent directories until reaching the root of your filesystem.

  3. The first .node-version file found by searching the current working directory and each of its parent directories until reaching the root of your filesystem. You can modify the .node-version file in the current working directory with the nodenv local command.

  4. The global ~/.nodenv/version file. You can modify this file using the nodenv global command. If the global version file is not present, nodenv assumes you want to use the "system" Node—i.e. whatever version would be run if nodenv weren't in your path.

Locating the Node Installation

Once nodenv has determined which version of Node your application has specified, it passes the command along to the corresponding Node installation.

Each Node version is installed into its own directory under ~/.nodenv/versions. For example, you might have these versions installed:

  • ~/.nodenv/versions/0.10.36/
  • ~/.nodenv/versions/0.12.0/
  • ~/.nodenv/versions/iojs-1.0.0/

Version names to nodenv are simply the names of the directories or symlinks in ~/.nodenv/versions.

Installation

Using Package Managers

  1. Install nodenv using one of the following approaches.

    Homebrew

    On macOS or Linux, we recommend installing nodenv with Homebrew.

    brew install nodenv

    Debian, Ubuntu, and their derivatives

    Presently, nodenv is not available in the Debian or Ubuntu package repositories. Consider contributing!

    Arch Linux and its derivatives

    Archlinux has an AUR Package for nodenv and you can install it from the AUR using the instructions from this wiki page.

  2. Set up nodenv in your shell.

    nodenv init

    Follow the printed instructions to set up nodenv shell integration.

  3. Close your Terminal window and open a new one so your changes take effect.

  4. Verify that nodenv is properly set up using this nodenv-doctor script:

    curl -fsSL https://github.com/nodenv/nodenv-installer/raw/main/bin/nodenv-doctor | bash
    Checking for `nodenv' in PATH: /usr/local/bin/nodenv
    Checking for nodenv shims in PATH: OK
    Checking `nodenv install' support: /usr/local/bin/nodenv-install (node-build 3.0.22-4-g49c4cb9)
    Counting installed Node versions: none
      There aren't any Node versions installed under `~/.nodenv/versions'.
      You can install Node versions like so: nodenv install 2.2.4
    Auditing installed plugins: OK
  5. That's it! Installing nodenv includes node-build, so now you're ready to install some Node versions using nodenv install.

Basic GitHub Checkout

For a more automated install, you can use nodenv-installer. If you prefer a manual approach, follow the steps below.

This will get you going with the latest version of nodenv without needing a systemwide install.

  1. Clone nodenv into ~/.nodenv.

    git clone https://github.com/nodenv/nodenv.git ~/.nodenv

    Optionally, try to compile dynamic bash extension to speed up nodenv. Don't worry if it fails; nodenv will still work normally:

    cd ~/.nodenv && src/configure && make -C src
  2. Add ~/.nodenv/bin to your $PATH for access to the nodenv command-line utility.

    • For bash:

      Ubuntu Desktop users should configure ~/.bashrc:

      echo 'export PATH="$HOME/.nodenv/bin:$PATH"' >> ~/.bashrc

      On other platforms, bash is usually configured via ~/.bash_profile:

      echo 'export PATH="$HOME/.nodenv/bin:$PATH"' >> ~/.bash_profile
    • For Zsh:

      echo 'export PATH="$HOME/.nodenv/bin:$PATH"' >> ~/.zshrc
    • For Fish shell:

      set -Ux fish_user_paths $HOME/.nodenv/bin $fish_user_paths
  3. Set up nodenv in your shell.

    ~/.nodenv/bin/nodenv init

    Follow the printed instructions to set up nodenv shell integration.

  4. Restart your shell so that PATH changes take effect. (Opening a new terminal tab will usually do it.)

  5. Verify that nodenv is properly set up using this nodenv-doctor script:

    curl -fsSL https://github.com/nodenv/nodenv-installer/raw/main/bin/nodenv-doctor | bash
    Checking for `nodenv' in PATH: /usr/local/bin/nodenv
    Checking for nodenv shims in PATH: OK
    Checking `nodenv install' support: /usr/local/bin/nodenv-install (node-build 3.0.22-4-g49c4cb9)
    Counting installed Node versions: none
      There aren't any Node versions installed under `~/.nodenv/versions'.
      You can install Node versions like so: nodenv install 2.2.4
    Auditing installed plugins: OK
  6. (Optional) Install node-build, which provides the nodenv install command that simplifies the process of installing new Node versions.

Upgrading with Git

If you've installed nodenv manually using Git, you can upgrade to the latest version by pulling from GitHub:

cd ~/.nodenv
git pull

To use a specific release of nodenv, check out the corresponding tag:

$ cd ~/.nodenv
$ git fetch
$ git checkout v0.3.0

Alternatively, check out the nodenv-update plugin which provides a command to update nodenv along with all installed plugins.

$ nodenv update

Updating the list of available Node versions

If you're using the nodenv install command, then the list of available Node versions is not automatically updated when pulling from the nodenv repo. To do this manually:

cd ~/.nodenv/plugins/node-build
git pull

How nodenv hooks into your shell

Skip this section unless you must know what every line in your shell profile is doing.

nodenv init is the only command that crosses the line of loading extra commands into your shell. Here's what nodenv init actually does:

  1. Sets up your shims path. This is the only requirement for nodenv to function properly. You can do this by hand by prepending ~/.nodenv/shims to your $PATH.

  2. Installs autocompletion. This is entirely optional but pretty useful. Sourcing ~/.nodenv/completions/nodenv.bash will set that up. There is also a ~/.nodenv/completions/nodenv.zsh for Zsh users.

  3. Rehashes shims. From time to time you'll need to rebuild your shim files. Doing this automatically makes sure everything is up to date. You can always run nodenv rehash manually.

  4. Installs the sh dispatcher. This bit is also optional, but allows nodenv and plugins to change variables in your current shell, making commands like nodenv shell possible. The sh dispatcher doesn't do anything invasive like override cd or hack your shell prompt, but if for some reason you need nodenv to be a real script rather than a shell function, you can safely skip it.

Run nodenv init - for yourself to see exactly what happens under the hood.

Installing Node versions

The nodenv install command doesn't ship with nodenv out of the box, but is provided by the node-build project. If you installed it as part of GitHub checkout process outlined above you should be able to:

# list latest stable versions:
nodenv install -l

# list all local versions:
nodenv install -L

# install a Node version:
nodenv install 16.13.2

Set a Node version to finish installation and start using commands nodenv global 18.14.1 or nodenv local 18.14.1

Alternatively to the install command, you can download and compile Node manually as a subdirectory of ~/.nodenv/versions/. An entry in that directory can also be a symlink to a Node version installed elsewhere on the filesystem. nodenv doesn't care; it will simply treat any entry in the versions/ directory as a separate Node version. Additionally, nodenv has special support for an lts/ subdirectory inside versions/. This works great with the nodenv-aliases plugin, for example:

cd ~/.nodenv/versions
mkdir lts

# Create a symlink that allows to use "lts/erbium" as a nodenv version
# that always points to the latest Node 12 version that is installed.
ln -s ../12 lts/erbium

Uninstalling Node versions

As time goes on, Node versions you install will accumulate in your ~/.nodenv/versions directory.

To remove old Node versions, simply rm -rf the directory of the version you want to remove. You can find the directory of a particular Node version with the nodenv prefix command, e.g. nodenv prefix 0.8.22.

The node-build plugin provides an nodenv uninstall command to automate the removal process.

Uninstalling nodenv

The simplicity of nodenv makes it easy to temporarily disable it, or uninstall from the system.

  1. To disable nodenv managing your Node versions, simply remove the nodenv init line from your shell startup configuration. This will remove nodenv shims directory from $PATH, and future invocations like node will execute the system Node version, as before nodenv.

    While disabled, nodenv will still be accessible on the command line, but your Node apps won't be affected by version switching.

  2. To completely uninstall nodenv, perform step (1) and then remove its root directory. This will delete all Node versions that were installed under `nodenv root`/versions/ directory:

     rm -rf `nodenv root`
    

    If you've installed nodenv using a package manager, as a final step perform the nodenv package removal:

    • Homebrew: brew uninstall nodenv
    • Archlinux and its derivatives: sudo pacman -R nodenv

Command Reference

Like git, the nodenv command delegates to subcommands based on its first argument. The most common subcommands are:

nodenv local

Sets a local application-specific Node version by writing the version name to a .node-version file in the current directory. This version overrides the global version, and can be overridden itself by setting the NODENV_VERSION environment variable or with the nodenv shell command.

nodenv local 0.10.0

When run without a version number, nodenv local reports the currently configured local version. You can also unset the local version:

nodenv local --unset

nodenv global

Sets the global version of Node to be used in all shells by writing the version name to the ~/.nodenv/version file. This version can be overridden by an application-specific .node-version file, or by setting the NODENV_VERSION environment variable.

nodenv global 0.10.26

The special version name system tells nodenv to use the system Node (detected by searching your $PATH).

When run without a version number, nodenv global reports the currently configured global version.

nodenv shell

Sets a shell-specific Node version by setting the NODENV_VERSION environment variable in your shell. This version overrides application-specific versions and the global version.

nodenv shell 0.11.11

When run without a version number, nodenv shell reports the current value of NODENV_VERSION. You can also unset the shell version:

nodenv shell --unset

Note that you'll need nodenv's shell integration enabled (step 3 of the installation instructions) in order to use this command. If you prefer not to use shell integration, you may simply set the NODENV_VERSION variable yourself:

export NODENV_VERSION=0.10.26

nodenv versions

Lists all Node versions known to nodenv, and shows an asterisk next to the currently active version.

$ nodenv versions
  0.8.22
  0.9.12
  * 0.10.0 (set by /Users/will/.nodenv/version)

This will also list symlinks to specific Node versions inside the ~/.nodenv/versions or ~/.nodenv/versions/lts directories.

nodenv version

Displays the currently active Node version, along with information on how it was set.

$ nodenv version
0.10.0 (set by /Users/OiNutter/.nodenv/version)

nodenv rehash

Installs shims for all Node executables known to nodenv (i.e., ~/.nodenv/versions/*/bin/* and ~/.nodenv/versions/lts/*/bin/*). Run this command after you install a new version of Node, or install an npm package that provides an executable binary.

$ nodenv rehash

note: the package-rehash plugin automatically runs nodenv rehash whenever an npm package is installed globally

nodenv which

Displays the full path to the executable that nodenv will invoke when you run the given command.

$ nodenv which npm
/Users/will/.nodenv/versions/0.10.26/bin/npm

nodenv whence

Lists all Node versions with the given command installed.

$ nodenv whence npm
0.10.0
0.9.12
0.8.22

Environment variables

You can affect how nodenv operates with the following settings:

name default description
NODENV_VERSION Specifies the Node version to be used.
Also see nodenv shell
NODENV_ROOT ~/.nodenv Defines the directory under which Node versions and shims reside.
Also see nodenv root
NODENV_DEBUG Outputs debug information.
Also as: nodenv --debug <subcommand>
NODENV_HOOK_PATH see wiki Colon-separated list of paths searched for nodenv hooks.
NODENV_DIR $PWD Directory to start searching for .node-version files.

Development

The nodenv source code is hosted on GitHub. It's clean, modular, and easy to understand, even if you're not a shell hacker.

Tests are executed using Bats:

$ bats test
$ bats test/<file>.bats

Please feel free to submit pull requests and file bugs on the issue tracker.

Credits

Forked from Sam Stephenson's rbenv by Will McKenzie and modified for node.

node-build's People

Contributors

byroot avatar chrisseaton avatar deepj avatar dependabot[bot] avatar depfu[bot] avatar eregon avatar github-actions[bot] avatar guilleiguaran avatar headius avatar hsbt avatar jasonkarns avatar jeremy avatar jnozsc avatar josh avatar koic avatar metalefty avatar minimum2scp avatar mislav avatar miyucy avatar msp-greg avatar nirvdrum avatar noahgibbs avatar nodenv-bot avatar oinutter avatar reedloden avatar sferik avatar sstephenson avatar web-flow avatar yuichiro-naito avatar yyuu avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

node-build's Issues

Error installing node since 2.2.0

I keep seeing this in the terminal grep: /usr/local/Cellar/node-build/2.2.0/bin/../package.json: No such file or directory whenever i run node-build --version.

Also tried on a different machine we started getting failures in installing node 5.6.0.

Whenever we ran the nodenv install 5.6.0 or node-build equivalent command we got the message again (grep: /usr/local/Cellar/node-build/2.2.0/bin/../package.json: No such file or directory) and it said could not copy binary file, try installing from source (-c).

Tried that too and it didn't work, so we switched back to 2.1.5 and everything worked fine.

Thanks!

Feature: Add test to screen definitions for acceptable domains

Would be nice to confirm that definition files are pulling from "trusted" domains to more quickly approve PRs.

Probably don't want an untrusted domain to fail the test. Since it doesn't necessarily mean it won't be merged. But a warning at the minimum.

'latest' build definitions

Should we have some 'latest' build definitions that are always pointing to latest releases? The nodejs distributions list includes:

image

We could just have some build definitions that point to those locations, though that would mean the local install name of those nodes would be node-latest or node-latest-v5.x; since the version name would be taken from the build definition and not "updated" after installation to reflect the actual version number.

Alternatively, we could try some kind of after-install hook to rename the version once it's installed.

Is this a good or bad idea? It seems the rbenv team have avoided this for a long time. Presumably they have reason? nvm has similar aliases like node which points to latest release and 5.0 which is latest 5.x release.

Deprecate jxcore functions

JXcore has been abandoned. The builds no longer work and are to be removed ( #175 ). The build functions shouldn't be removed abruptly, as there may be people still relying on them, even with custom build definitions.

First step is to add warning messages to all the to-be-deprecated functions. That would be released as a minor version.

Then in the next major version bump, the functions could be removed entirely.

SHA256 mismatch

On brew upgrade node-build from node-build v2.6.7 brew returns the following error:

Error: SHA256 mismatch
Expected: c98f7de6a749520fb7155c1b315f01804eb6554f8edb0d45bd7514f9e9a1dc44
Actual: 6c636ae7bcead1186ee392cd9974e764cb0ba82165396366d502987f0d3c466f

Handle "binary-only" releases

Many Release Candidates and virtually every Nightly node release doesn't include every single platform. The way the current binary support works, anything missing just falls back to a from-source compile. However, there are also rare instances where a nightly or release candidate doesn't include a source package.

I'm not exactly sure how the 'nightly' definition handles this right now (I believe it just skips it entirely, falling back to a previous nightly). However, now that the node-build definition scraper supports published Release Candidates; we should probably handle these rare instances where a build definition is only binaries.

Include node-build version number in help output

To help with issues like #102 , we need to be able to see the node-build version number.

Presently, the version number only prints when invoking node-build directly (ie, outside of nodenv).

Need to:

  • add --version flag to nodenv-install command
  • include version in nodenv-install (and nodenv-uninstall?) help output

We should also consider how to unify the help output between the node-build command itself, and the nodenv-install/nodenv-uninstall commands.

Help maintaining repo?

Would you like some help maintaining this project? I would be willing to help test/merge PRs

how do I force node-build to use homebrew openssl?

originally from nodenv/nodenv#78

for example, in ruby:

RUBY_CONFIGURE_OPTS=--with-openssl-dir=/usr/local/opt/openssl rbenv install -s "$ruby_version"

in python:

CFLAGS=-I/usr/local/opt/openssl/include LDFLAGS=-L/usr/local/opt/openssl/lib pyenv install -s "$python_version"

trying to figure out how to do this with nodenv. thanks!

Accept version with 'v' prefix

I should be able to install node versions with the 'v' prefix. e.g.

$ node-build v8.5.0 ~/local/node-8.5.0

This allows my .node-version file to have v8.5.0 in it. This is consistent with the output of

$ node --version
v8.5.0

Unable to install 4.x-dev or 4.x-next

$ nodenv install 4.x-dev
Cloning https://github.com/nodejs/node.git...
Installing 4.x-dev...

BUILD FAILED (OS X 10.11.4 using node-build 2.2.6)

Inspect or clean up the working tree at /var/folders/cg/tn3c27yx4mv4c06p9gh19yzh0000gn/T/node-build.20160406120148.7277
Results logged to /var/folders/cg/tn3c27yx4mv4c06p9gh19yzh0000gn/T/node-build.20160406120148.7277.log

Last 10 log lines:
                 'v8_enable_i18n_support': 0,
                 'v8_no_strict_aliasing': 1,
                 'v8_optimized_debug': 0,
                 'v8_random_seed': 0,
                 'v8_use_snapshot': 'true',
                 'want_separate_host_toolset': 0,
                 'xcode_version': '7.3'}}
creating  ./config.gypi
creating  ./config.mk
make: *** empty string invalid as file name.  Stop.

I get the same errors for both, using nodenv v1.0.0 - please let me know if I can provide any other information. I have eval "$(nodenv init -)" in my ~/.bash_profile, and I've restarted my terminal and seen no errors in its execution, so I'm not sure what's going on.

NODE_BUILD_MIRROR_URL not working?

Hi there. I installed nodenv 1.1.1 and then installed node-build

git clone https://github.com/nodenv/node-build.git
cd node-build
./install.sh

But when I try using a mirror, it still reaches out to https://nodejs.org

~ # export NODE_BUILD_MIRROR_URL=http://internal-artifactory.com:8081/artifactory/nodejs/dist/
~ # nodenv install 4.2.1
sha256sum: unrecognized option: quiet
BusyBox v1.24.2 (2017-01-18 14:13:46 GMT) multi-call binary.

Usage: sha256sum [-c[sw]] [FILE]...

Print or check SHA256 checksums

	-c	Check sums against list in FILEs
	-s	Don't output anything, status code shows success
	-w	Warn about improperly formatted checksum lines
Downloading node-v4.2.1-linux-x64.tar.gz...
-> https://nodejs.org/dist/v4.2.1/node-v4.2.1-linux-x64.tar.gz
error: failed to download node-v4.2.1-linux-x64.tar.gz

Did I miss a step? Thanks!

Display a progress-bar when downloading prebuilt Nodes

When I execute nodenv install 8.1.4, I get something like this:

Downloading node-v8.1.4-darwin-x64.tar.gz...
-> https://nodejs.org/dist/v8.1.4/node-v8.1.4-darwin-x64.tar.gz

When on a slow WiFi or VPN, it can sit there for … quite a while. Exposing aria2c's progress bar or something like that would really improve the UX!

Tag Node releases for Homebrew

For homebrew tags are used to identify a build. Because of that, I'd like to ask you to tag every Node release, so node-build's formula can be updated. The latest tag only gives access to Node 5.1.0, but I'd like to use later versions.

add subcommand to run the scraper as a user

The scraper is really helpful for adding node definitions to node-build directly. But it would be more awesome if the scraper could be invoked by a user through a subcommand so that users could get latest definitions even before they are in master.

Concerns:

  • scraper requires node, so the command may fail if run on certain (older) versions of node
  • scraper would fail if the command is run on a system without any nodes installed
  • any new definitions would appear as new (untracked) files in node-build/share; this could prevent simple git pull from succeeding when those same definitions become available in master (breaking nodenv-update); this might impact homebrew installs as well. Solution? Write user-generated definitions to the custom-definition directory.

Push first release

Are you ready to push an initial release? I'm setting up a custom Homebrew tap for this and nodenv, and it would be helpful to provide a formula that's not head-only.

Remove jxcore build definitions

jxcore development has ceased and none of the packages are available on amazon any longer, so the builds no longer function.

Update Homebrew version

The version on Homebrew is outdated. I can still install the most recent with brew [re]install --HEAD node-build but I think node-build should be properly re-published to the Homebrew directory when new build definitions are available.

Support prefix moving

We would like to have definitions like latest, nightly, lts, current, etc which pull down the "latest" respective version. Ideally, we would like the installed version to be named precisely per the version number as having an installed version named latest is hardly useful after a few days.

  • perhaps attempt to mv the version in after_install_package hook, accounting for PREFIX_PATH (see #236 )
  • perhaps attempt to modify the PREFIX_PATH as part of the definitions "main" run, rather than in hooks?
  • perhaps we need to expose a hook in node-build that a definition can invoke to force/override the installed package name?

Questions to resolve:

  1. What to do when a given architecture is not included in the specified "latest" build? Should it build latest from source? Or get a slightly older version that does have a binary build? This would require checking platform in the build definition itself.
  2. What to do when the "latest" is already installed? The pre-install check that node-build performs is based on the build definition filename. This will be insufficient if the version name isn't known until the definition is run.

closes #145

4.2.0 and 4.2.1 errors out on ubuntu 12.04

g++ '-DV8_TARGET_ARCH_X64' '-DENABLE_DISASSEMBLER' '-DV8_IMMINENT_DEPRECATION_WARNINGS' '-DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC' -I../deps/v8 -pthread -Wa
ll -Wextra -Wno-unused-parameter -m64 -B/tmp/node-build.20151022160705.24506/node-v4.2.1/third_party/binutils/Linux_x64/Release/bin -fno-strict-aliasing -m64 -O3 -ffunction-sections -fdata-sections -fno-omit-frame-pointer -fdata-sections -ffunction-sections -O3 -fno-rtti -fno-exceptions -std=gnu++0x -MMD -MF /tmp/node-build.20151022160705.24506/node-v4.2.1/out/Release/.deps//tmp/node-build.20151022160705.24506/node-v4.2.1/out/Release/obj.target/v8_base/deps/v8/src/accessors.o.d.raw -c -o /tmp/node-build.20151022160705.24506/node-v4.2.1/out/Release/obj.target/v8_base/deps/v8/src/accessors.o ../deps/v8/src/accessors.cc
In file included from ../deps/v8/src/v8.h:29:0,
from ../deps/v8/src/accessors.cc:5:
../deps/v8/include/v8.h:469:1: error: expected unqualified-id before 'using'
../deps/v8/include/v8.h:852:1: error: expected unqualified-id before 'using'
In file included from ../deps/v8/src/base/platform/platform.h:29:0,
from ../deps/v8/src/utils.h:18,
from ../deps/v8/src/v8.h:34,
from ../deps/v8/src/accessors.cc:5:
../deps/v8/src/base/platform/mutex.h:36:13: error: variable 'v8::base::Mutex v8::base::final' has initializer but incomplete type
../deps/v8/src/base/platform/mutex.h:37:2: error: expected primary-expression before 'public'
../deps/v8/src/base/platform/mutex.h:37:2: error: expected '}' before 'public'
../deps/v8/src/base/platform/mutex.h:37:2: error: expected ',' or ';' before 'public'
../deps/v8/src/base/platform/mutex.h:39:11: error: expected constructor, destructor, or type conversion before ';' token
../deps/v8/src/base/platform/mutex.h: In function 'v8::base::NativeHandle& v8::base::native_handle()':
../deps/v8/src/base/platform/mutex.h:63:12: error: 'native_handle_' was not declared in this scope
../deps/v8/src/base/platform/mutex.h: At global scope:
../deps/v8/src/base/platform/mutex.h:65:39: error: non-member function 'const NativeHandle& v8::base::native_handle()' cannot have cv-qualifier
../deps/v8/src/base/platform/mutex.h: In function 'const NativeHandle& v8::base::native_handle()':
../deps/v8/src/base/platform/mutex.h:65:39: error: new declaration 'const NativeHandle& v8::base::native_handle()'
../deps/v8/src/base/platform/mutex.h:62:17: error: ambiguates old declaration 'v8::base::NativeHandle& v8::base::native_handle()'
../deps/v8/src/base/platform/mutex.h:66:12: error: 'native_handle_' was not declared in this scope
../deps/v8/src/base/platform/mutex.h: At global scope:
../deps/v8/src/base/platform/mutex.h:69:2: error: expected unqualified-id before 'private'
../deps/v8/src/base/platform/mutex.h:89:3: error: 'friend' used outside of class
../deps/v8/src/base/platform/mutex.h:91:3: error: expected unqualified-id before 'const'
../deps/v8/src/base/platform/mutex.h:91:3: error: expected ')' before 'const'
../deps/v8/src/base/platform/mutex.h:91:3: error: 'void v8::base::operator=(const v8::base::Mutex&)' must be a nonstatic member function
../deps/v8/src/base/platform/mutex.h:104:9: error: 'LazyStaticInstance' does not name a type
../deps/v8/src/base/platform/mutex.h:130:22: error: variable 'v8::RecursiveMutex v8::final' has initializer but incomplete type
../deps/v8/src/base/platform/mutex.h:131:2: error: expected primary-expression before 'public'
../deps/v8/src/base/platform/mutex.h:131:2: error: expected '}' before 'public'
../deps/v8/src/base/platform/mutex.h:131:2: error: expected ',' or ';' before 'public'
../deps/v8/src/base/platform/mutex.h:133:20: error: expected constructor, destructor, or type conversion before ';' token
../deps/v8/src/base/platform/mutex.h:155:11: error: 'Mutex' does not name a type
../deps/v8/src/base/platform/mutex.h:157:3: error: 'NativeHandle' does not name a type
../deps/v8/src/base/platform/mutex.h:160:9: error: 'NativeHandle' does not name a type
../deps/v8/src/base/platform/mutex.h:164:2: error: expected unqualified-id before 'private'
../deps/v8/src/base/platform/mutex.h:170:3: error: expected unqualified-id before 'const'
../deps/v8/src/base/platform/mutex.h:170:3: error: expected ')' before 'const'
../deps/v8/src/base/platform/mutex.h:170:3: error: 'void v8::operator=(const v8::RecursiveMutex&)' must be a nonstatic member function
../deps/v8/src/base/platform/mutex.h:184:9: error: 'LazyStaticInstance' does not name a type
../deps/v8/src/base/platform/mutex.h:202:17: error: template declaration of 'LockGuard final'
../deps/v8/src/base/platform/mutex.h:203:2: error: expected primary-expression before 'public'
../deps/v8/src/base/platform/mutex.h:203:2: error: expected '}' before 'public'
../deps/v8/src/base/platform/mutex.h:205:14: error: declaration of '~LockGuard' as non-member
../deps/v8/src/base/platform/mutex.h:207:2: error: expected unqualified-id before 'private'
../deps/v8/src/base/platform/mutex.h:210:3: error: expected unqualified-id before 'const'
../deps/v8/src/base/platform/mutex.h:210:3: error: expected ')' before 'const'
../deps/v8/src/base/platform/mutex.h:210:3: error: 'void operator=(const LockGuard&)' must be a nonstatic member function
../deps/v8/src/base/platform/mutex.h:211:1: error: expected declaration before '}' token
../deps/v8/src/base/platform/mutex.h: In function 'const NativeHandle& v8::base::native_handle()':
../deps/v8/src/base/platform/mutex.h:67:3: warning: control reaches end of non-void function [-Wreturn-type]
../deps/v8/src/base/platform/mutex.h: In function 'v8::base::NativeHandle& v8::base::native_handle()':
../deps/v8/src/base/platform/mutex.h:64:3: warning: control reaches end of non-void function [-Wreturn-type]
make[1]: *** [/tmp/node-build.20151022160705.24506/node-v4.2.1/out/Release/obj.target/v8_base/deps/v8/src/accessors.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory `/tmp/node-build.20151022160705.24506/node-v4.2.1/out'
make: *** [node] Error 2

New checksums released today?

Hi there,

As part of our CI process we use node-build to install whatever node is listed in a repo's .node-version file. Today our builds started failing because the checksum for node v6.9.2 was not matching.

I see that in the latest node-build, the expected checksum for linux-x64 is cbf6a35b035c56f991c2e6a4aedbcd9f09555234ac0dd5b2c15128e2b5f4eb50, but the official nodejs checksum is c8acada3301857ddb650bc9d4383eaba4b90ebd4d89740729297bffb630a3531 (from https://nodejs.org/dist/v6.9.2/SHASUMS256.txt.asc).

If you gpg --verify that checksum file, you'll see that the signature was created today, suggesting to me that the checksums were changed today.

I'd love to contribute by updating the checksums in node-build to match the latest ones published from the node team -- is there any kind of automation around this process that you guys have built?

Thanks a lot, we really love nodenv and all its plugins!

gcc compiler

ruby is well known for having issues compiling on different c compilers. Older versions of ruby would only build on the official gcc compiler (not apple's llvm); and lately ruby-build defaults many builds to clang.

Do any specific node versions have issues with certain c compilers?

Yank jxcore build defs

I'd like to yank the jxcore build defs. (I don't believe they even build successfully anymore with most assets having gone offline.)

Before we do that, I'd like to create a separate nodenv plugin as a repository of "archived" build definitions. That way people who would like access to the old build defs (for whatever reason) can do so through the extra plugin.

Nightly build(s) fail

$ nodenv install nightly 
Downloading node-v8.0.0-nightly20170210b471392f8c-darwin-x64.tar.gz...
-> https://nodejs.org/download/nightly/v8.0.0-nightly20170210b471392f8c/node-v8.0.0-nightly20170210b471392f8c-darwin-x64.tar.gz
Installing node-v8.0.0-nightly20170210b471392f8c-darwin-x64...
find: /usr/local/var/nodenv/versions/nightly: No such file or directory

BUILD FAILED (OS X 10.12.3 using node-build 2.5.4)

Binary installation failed; try compiling from source with `--compile` flag

Inspect or clean up the working tree at /var/folders/sv/3941ksds4v18r9y1kyptw1jw0000gn/T/node-build.20170210213852.81278
Results logged to /var/folders/sv/3941ksds4v18r9y1kyptw1jw0000gn/T/node-build.20170210213852.81278.log

Last 10 log lines:
/var/folders/sv/3941ksds4v18r9y1kyptw1jw0000gn/T/node-build.20170210213852.81278 ~/Projects/node-build
/var/folders/sv/3941ksds4v18r9y1kyptw1jw0000gn/T/node-build.20170210213852.81278/node-v8.0.0-nightly20170210b471392f8c-darwin-x64 /var/folders/sv/3941ksds4v18r9y1kyptw1jw0000gn/T/node-build.20170210213852.81278 ~/Projects/node-build

The directory permissions fixing (

fix_directory_permissions
) is throwing an error at
find "$PREFIX_PATH" -type d \( -perm -020 -o -perm -002 \) -exec chmod go-w {} \;
because the after_install hook has run which has moved the new node.

script for getting iojs builds from github tags

I didn't notice there were already scrapers in the repo for getting iojs versions.

This is the shell script I used to get the ones I submitted yesterday:

curl https://api.github.com/repos/iojs/io.js/tags | jq -r '.[].name' | {
while read iojstag; do 
  iojsversion=${iojstag#v}
  echo "install_git \"iojs-$iojsversion\" \"https://github.com/iojs/io.js.git\" \"$iojstag\" standard" > share/node-build/iojs-$iojsversion
done
}

thought it might be helpful

Merge upstream ruby-build changes

Howdy,

I have several branches lined up for the recent iojs releases (1.0.0 through 1.1.0) that I want to eventually get merged in. However, they fail to build because the current implementation of checksum verification assumes sha1 which is incompatible with the sha256 backed checksums being used for iojs releases. As such, I would need to do some tweaking beyond the typical one-liners I've been adding to share/node-build in order to get the iojs releases to properly build.

Before I embark on any changes that would cause us to further divert from ruby-build, however, I thought it might be worthwhile to pull in the compatible upstream changes/features that have been made in ruby-build. Considering the difference in build versions (201300310 vs 20150130), I think a few things have changed 😛.

What are your thoughts? I'm more than happy to see this process through and make a PR for it, but I just wanted to make sure that you would be receptive to these changes before I spend the time making them. It might also be worth discussing how to handle future upstream changes.

Thanks!

nodenv install not working

Hi, I tried installing nodenv for node version 10.8.0 with command
$nodenv install 10.8.0

It gave message downloading then nothing happened after.
Downloading node-v10.8.0-linux-x64.tar.gz...
-> https://nodejs.org/dist/v10.8.0/node-v10.8.0-linux-x64.tar.gz

compilation flags (readline? yaml? openssl?)

ruby-build has an awful lot of code for enabling certain common ./configure flags; specifically, readline, yaml, and openssl. There's even more code for using homebrew's variants by default, if available. However, I'm not very familiar with which flags would be relevant for node. Are any of these flags relevant for node? Are there any others that we should be handling specially?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.