add debug build

[gengjiawen]

• add recipe
• decide which folder should it in
• Integrated with n and nvm

We discussed this in today's Release WG meeting and the consensus of the Release WG is that this should first be attempted as an https://unofficial-builds.nodejs.org/ / https://github.com/nodejs/unofficial-builds/ project.

@MylesBorins may be able to help with storage via Google credits.

Originally posted by @richardlau in nodejs/Release#555 (comment)

[gengjiawen]

The github workflow should be like this(https://github.com/gengjiawen/node-github-workflow/blob/master/.github/workflows/CI.yml)

I guess xz format will be much better ? cc @rvagg

name: CI

on: [push, pull_request]

jobs:
  build-linux-debug:
    runs-on: ubuntu-latest
    container: gengjiawen/node-build
    steps:
      - uses: actions/checkout@v2
      - name: Environment Information
        run: npx envinfo
      - run: git clone -b v13.11.0 --single-branch https://github.com/nodejs/node --depth=10
      - name: Build
        run: cd node && ./configure --debug && make -j2
      - run: 7z a node-debug.7z node/out/Debug/node
      - uses: actions/upload-artifact@v1
        with:
          name: node-debug-build
          path: node-debug.7z

[rvagg]

7z, xz .. I think I'd prefer xz because it's more common, but I've just discovered I have 7z on my Ubuntu 18.04 machine which I guess it came with so maybe it's not too bad a choice.

The way to pull this off is to make a new folder in the recipes folder and make a Dockerfile to set up an image to build the file and also a run.sh to perform the build. Copying the x86 one might be a good start:

• https://github.com/nodejs/unofficial-builds/blob/master/recipes/x86/Dockerfile
• https://github.com/nodejs/unofficial-builds/blob/master/recipes/x86/run.sh

You can test that it works by building the image and tagging it, then grabbing a Node.js tarball, then running it with something like:

  docker run --rm \
    -v /path/to/node-vxxx.tar.gz:/home/node/node.tar.xz -v /path/to/output/dir:/out \
    tagforyourimage \
    "$unofficial_release_urlbase" "$disttype" "$customtag" "$datestring" "$commit" "$fullversion" "$source_url"

where $unofficial_release_urlbase is "https://unofficial-builds.nodejs.org/download/${disttype}/"
$disttype is probably "release", $customtag, $datestring, and $commitare empty$fullversionis the version string of build (prefixed withvI think). I don't think$source_url` is needed for this but it's the location of the original source file that you downloaded.

[mmarchini]

If we're publishing a Debug build with the purpose of improving debugging experience on native add-ons, we should probably include deps/v8/tools/gdbinit and deps/v8/tools/lldb_commands.py in the bundle as well.

[gengjiawen]

I am inclined not bundled them, I have a package has command to do such thing (only for lldb now).
https://github.com/gengjiawen/node-build

npm i -g @gengjiawen/node-dev
node-dev -h
node-dev setuplldb

[mmarchini]

Those scripts are highly dependant on V8 version, we can't use the script from v12 with v10 or vice versa, for example.

[gengjiawen]

Those scripts are highly dependant on V8 version, we can't use the script from v12 with v10 or vice versa, for example.

Maybe a script to directly to get the script from v8 repo. we can get v8 version from process.versions.

[gengjiawen]

Still not getting how to do this, my thinking is to build the Node.js core and copy to related folder (foler name should be the version).

FROM gengjiawen/node-build

ARG NODE_VERSION

RUN npx envinfo
RUN echo "building $NODE_VERSION"
RUN git clone -b v${NODE_VERSION} --single-branch https://github.com/nodejs/node --depth=10
RUN cd node && ./configure --debug && make -j2
RUN xz -9 out/Debug/node

[rvagg]

@gengjiawen do you mean for unofficial-builds or for the scripts @mmarchini is talking about?

For unofficial-builds, cp -a x86 linux-x64-debug and edit the contents of those files to make it do a debug binary and we'll go from there. We might need to rethink that name for what we want it to be in the downloads directory.

[mmarchini]

FWIW I don't think we should block anything because of the scripts, we can add it later if we want to (I can do it once we have the build recipe).

[gengjiawen]

@gengjiawen do you mean for unofficial-builds or for the scripts @mmarchini is talking about?

Nope, I tried to build the debug part, but still not get how to do it. I am not familiar with bash.

Is there an easy way, the build part is easy #17 (comment).

But I have no clue integrate it with current system.

[mmarchini]

@gengjiawen do you mind if I give it a try?

[gengjiawen]

@gengjiawen do you mind if I give it a try?

Not at all, go ahead :)

[mmarchini]

Well, it's going to be less straightforward than I thought, since the target we usually use for releases assumes the build is, well, a Release:

https://github.com/nodejs/node/blob/master/Makefile#L1163-L1185

[rvagg]

Yeah, that's a bit of a doozy, but I think all of the stuff in Makefile that builds these should be relatively easy to replace in a run.sh script.

What are the resulting assets from this recipe are we aiming for? A single node debug binary, a tarball like a normal linux-x64 but debug? a collection of things to mixin with a normal tarball from nodejs.org? How much of that make-tarball-from-binary stuff in Makefile would we need to reproduce?

The most complicated stuff in there is running configure but it's really not as complicated as it seems if we're limiting ourselves just to release builds (as in download/release/ builds, not nightlies).