repo ships binary of gn in buildtools

[lubic...@gmail.com]

Hi Guys,

I'm working on a dart runtime build for alpine linux. Unfortunately there are some complications regarding the musl libc. So I work to solve them step by step. 

Right now I want only to ask what are the reasons for having `gn` bundled in the repo unter buildtools which is a binary of course not build against the musl libc and therefore the not working under alpine. 

I totally get the convenience aspect of shipping the buildchain with the repo, but is there either a way to workaround this or a plan to clean that up?

Cheers

Sven

[Vyacheslav Egorov]

Hi Sven,

> I totally get the convenience aspect of shipping the buildchain with the repo, but is there either a way to workaround this or a plan to clean that up?

To be precise GN binary is not shipped with the repo, it's pulled down from CIPD based on the platform. 

Unfortunately Alpine Linux is not recognized as a special platform - so gclient just pulls down generic linux version of the tool. 

The only workaround for this is to build your own GN and replace sdk/buildtools/gn with it after you synced the source.

// Vyacheslav Egorov

--
You received this message because you are subscribed to the Google Groups "Dart VM Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vm-dev+un...@dartlang.org.

[Sven Aßmann]

Hi Vyacheslav,

thanks for your feedback.

To be precise GN binary is not shipped with the repo, it's pulled down from CIPD based on the platform. 

Sorry that was my bad, I ran the tools on my mac and then in the docker container the files where there but of course not working. There are a lot of problems with the CIPD packaged files, e.g. they are all linked to the regular glibc and therefore not compatible with the musl-libc of alpine. This also is true for other tools in the build chain where certain python wheels are fetched. That is why I need to run fetch for instance on a different machine first.   

The only workaround for this is to build your own GN and replace sdk/buildtools/gn with it after you synced the source.

Done that but unfortunately it still does not work.

```

bash-4.4# ./tools/build.py --verbose --mode release --arch x64 runtime

gn gen --check in out/ReleaseX64

Command failed: /tmp/app/sdk/buildtools/gn gen out/ReleaseX64 --args=exclude_kernel_service=false is_product=false dart_runtime_mode="develop" dart_use_crashpad=false dart_use_debian_sysroot=true dart_platform_bytecode=false use_goma=false dart_platform_sdk=false is_msan=false is_release=true is_clang=true dart_stripped_binary="exe.stripped/dart" dart_target_arch="x64" dart_use_tcmalloc=true goma_dir="None" dart_debug=false host_cpu="x64" dart_snapshot_kind="app-jit" is_tsan=false target_os="linux" dart_vm_code_coverage=false dart_use_fallback_root_certificates=true target_cpu="x64" is_asan=false is_debug=false

output: ERROR at //build/dart/dart_action.gni:101:3: Assertion failed.

  assert(_is_fuchsia || prebuilt_dart_exe_works,

  ^-----

A pre built dart executable needs to be present

See //build/dart/dart_action.gni:180:3: whence it was called.

  _prebuilt_tool_action(target_name) {

  ^-----------------------------------

See //utils/kernel-service/BUILD.gn:63:1: whence it was called.

prebuilt_dart_action("kernel_service_dill") {

^--------------------------------------------

See //BUILD.gn:50:5: which caused the file to be included.

    "utils/kernel-service:kernel-service",

    ^------------------------------------

Tried to run GN, but it failed. Try running it manually:

$ python /tmp/app/sdk/tools/gn.py -m release -a x64 --os host -v

ninja -C out/ReleaseX64 -v runtime

ninja: Entering directory `out/ReleaseX64'

ninja: error: loading 'build.ninja': No such file or directory

BUILD FAILED

```

I don’t fully understand why this check insists on a pre-installed dart: prebuilt_dart_exe_works

Do you know a way of disable this check and build without the pre build dart binary?

Cheers

Sven

[Vyacheslav Egorov]

> I don’t fully understand why this check insists on a pre-installed dart: prebuilt_dart_exe_works

There are parts of the Dart toolchain that are written in Dart, e.g. Dart parser is written in Dart. 

This creates circular dependency during build - to be able to parse Dart code you need to be able to run Dart code already. 

Right now we just expect to have a prebuilt SDK which can be used to break this dependency. 

There are other alternatives to break this cycle but we did not implement those. 

// Vyacheslav Egorov