Deno: option to setup/build only use native

[hayd]

i.e. without using any prebuilts.
Examples: rust, cargo, rustfmt, v8(?), etc.

This comes up when repos are wanting to build deno from scratch e.g. brew (who are loathe to add binary deps).
Also with Alpine docker to use native musl I think it would have to build or apk each component itself (it can't use the prebuilt because it's not compatible).

Hopefully I'm explaining this correctly..

[ry]

Yes I agree.

The only bundled binaries that are involved in producing the deno executable are chrome's clang toolchain (located at //third_party/llvm-build/Release+Asserts). We don't bundle rust, so that's out of our hands.

We ought to have some documentation on how to use a system clang installation. The way it's done is by appending the following lines to target/release/args.gn

clang_base_path = "/usr"
clang_use_chrome_plugins = false

See also https://cs.chromium.org/chromium/src/build/config/clang/clang.gni

That said, I realize that setup.py downloads other binaries that we need for other purposes and that we have binaries in third_party also not involved in the build.

As a first step, we should move //third_party/wrk and //third_party/rustfmt to //prebuilt. After that's done, we ca modify setup.py to take a flag telling it to not download any binaries.

[hayd]

Is there a minimum version of clang required to build?

I had been trying to build on alpine's clang 5 and get a bunch of unrecognized flag errors.

[hayd]

Is this also required for ARM support?

[anxiousmodernman]

This flag now exists on ./tools/setup.py

  --no-binary-download  Do not download binaries, must use depot_tools
                        manually

[hayd]

Is there still some feedback here, the home-brew formula uses this to install https://github.com/Homebrew/homebrew-core/pull/35645/files

Specifically, optionally env look up/pass locations for ninja + gn (+ sccache)? Also not to use sccache (I think that might be using gn and not setup+build).

https://github.com/Homebrew/homebrew-core/pull/35645#issuecomment-495235566

I've just moved our from source compiled gn binary to the expected location (where depot_tools would put it's binary downloads) to avoid patching the gn_path of the build system (the patched ninja_path was already unnecessary since we call the ninja binary directly and it's not called in a subprocess).

Edit: Perhaps this is okay as is, and we can close this issue.

[chrmoritz]

I think there is still room for improvements.

Here is an even simpler homebrew formula which requires 2 small patches to denos build ./tools to make it work using your setup.py and build.py scripts by passing all required options in through environment variables.

• The first patch to ./tools/third_party.py simply adds the option to override the default gn_path and ninja_path by setting the DENO_GN_PATH and DENO_NINJA_PATH environment variables. (Not sure if adding 2 new environment variables is the best solution here, but they have to persist to subprocess spawned by gn.)
• The second patch to ./tools/setup.py fixes setup.py's --no-binary-download option to also disable the download of the sccache binary.

Would something like this be acceptable here?

[hayd]

@chrmoritz looks great to me!

[hayd]

@chrmoritz Please can you make a PR from that branch, this would be really useful outside of brew.