New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 885139 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
OoO until Feb 4th
Closed: Sep 19
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug


Show other hotlists

Hotlists containing this issue:
Chromium-Packagers


Sign in to add a comment

gn bootstrap: calling the gn binary should be at least optional

Project Member Reported by raphael....@intel.com, Sep 18

Issue description

I've finally had some time to take a closer look at https://chromium-review.googlesource.com/c/chromium/src/+/1136495 and related changes, and try to build M69 with my downstream hat.

From a distro perspective, unconditionally calling gn after building it is problematic especially from a cross-compilation perspective. GN itself can just be built and run on the host to generate build.ninja, which means the dependencies installed on the system are not those that Chromium itself needs.

Before uploading any CLs, I'd like to see if this would be OK:
- Separate building GN from running GN (which was the case before GN was moved out of //src)
- Consequently, drop --with-sysroot and --gn-gen-args from bootstrap.py
- Adjust build_from_tarball.py accordingly
 
Cc: thakis@chromium.org
> From a distro perspective, unconditionally calling gn after building it is problematic especially from a cross-compilation perspective. GN itself can just be built and run on the host to generate build.ninja, which means the dependencies installed on the system are not those that Chromium itself needs.

I'm not sure I understand why this is an issue.  gn is a tool meant to run only on the host.  It shouldn't matter if the target arch is different, or has different dependencies, right?
If gn is being built in a machine or sysroot without Chromium's dependencies (or even X, for example), to then be run somewhere else with the proper dependencies, having bootstrap.py invoke 'gn gen' on the Chromium checkout in the host will fail even though the whole process should just work.
Could we instead add an option --skip-generate-buildfiles ?

We added the new tools/gn/bootstrap/bootstrap.py specifically for backwards-compatibility, so I wouldn't want to remove any options or features.
One could argue that the proposed behavior actually restores backwards-compatibility, as bootstrap.py didn't do this before GN was split from //src. I can add an option if that's preferred though.
> One could argue that the proposed behavior actually restores backwards-compatibility, as bootstrap.py didn't do this before GN was split from //src. 

It did run gn before.  It only didn't if --no-rebuild was passed.  This option is now ignored, but it should probably skip generating the build files too.

> I can add an option if that's preferred though.

SGTM
Project Member

Comment 6 by bugdroid1@chromium.org, Sep 19

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/79c741fd88a1cab596a38afde628c52f21dbe4a2

commit 79c741fd88a1cab596a38afde628c52f21dbe4a2
Author: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Date: Wed Sep 19 18:16:40 2018

gn: Add --skip-generate-buildfiles to bootstrap.py

This restores part of --no-rebuild's behavior: we only build GN but do not
run it afterwards when the option is specified. It's particularly useful
when GN is built in a different machine or sysroot than the one where
Chromium itself will be built (often with different dependencies installed
on the system).

Bug:  885139 
Change-Id: If9f3386db8324b47b52864bccc685578fd40a689
Reviewed-on: https://chromium-review.googlesource.com/1233708
Reviewed-by: Thomas Anderson <thomasanderson@chromium.org>
Commit-Queue: Raphael Kubo da Costa (CET) <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/master@{#592479}
[modify] https://crrev.com/79c741fd88a1cab596a38afde628c52f21dbe4a2/tools/gn/bootstrap/bootstrap.py

Status: Fixed (was: Available)
Labels: Target-71
Owner: raphael....@intel.com

Sign in to add a comment