Downstream breakage from //build roll

[geisserml]

Hi,

I recently updated our downstream pdfium build config from 7191 to 7828, [1] and encountered some breakage.

In particular, the //build roll from [2] has caused this error:

```

['gn', 'gen', 'out/Default'] (cwd=PosixPath('/home/me/projects/pypdfium2/sbuild/native/pdfium'))
ERROR at //build/toolchain/gcc_toolchain.gni:357:17: Unknown substitution pattern
      command = "$cxx -MD -MF $depfile {{defines}} {{include_dirs}} {{cflags}} {{cflags_cc}}${extra_cppflags}${extra_cxxflags} {{module_deps_no_self}} -fmodule-name={{cc_module_name}} -x c++ -Xclang -emit-module -c {{source}} -o {{output}}"
                ^-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Found a {{ at offset 136 and did not find a known substitution following it.
See //build/toolchain/gcc_toolchain.gni:905:3: whence it was called.
  single_gcc_toolchain(target_name) {
  ^----------------------------------
See //build/toolchain/linux/custom/BUILD.gn:3:1: whence it was called.
gcc_toolchain("default") {
^-------------------------
See //BUILD.gn:10:1: which caused the file to be included.
group("default") {
^-----------------

```

Below is the build config used, but I suspect it also happens with some other configs. In particular, I also saw the issue with is_clang = true.

```

is_debug = false
use_glib = false
use_remoteexec = false
treat_warnings_as_errors = false
clang_use_chrome_plugins = false
is_component_build = false
pdf_is_standalone = true
pdf_enable_v8 = false
pdf_enable_xfa = false
pdf_use_skia = false
pdf_use_partition_alloc = false
use_sysroot = false
use_custom_libcxx = false
is_clang = false
custom_toolchain = "//build/toolchain/linux/custom:default"
host_toolchain = "//build/toolchain/linux/custom:default"

```

I then took a look at the commit log and tracked down the cause to [3].

Reverting that renaming with the patch below seemed to fix this issue:

```

diff --git a/toolchain/gcc_toolchain.gni b/toolchain/gcc_toolchain.gni
index 6da1768..409d213 100644
--- a/toolchain/gcc_toolchain.gni
+++ b/toolchain/gcc_toolchain.gni
@@ -354,7 +354,7 @@ template("single_gcc_toolchain") {
 
       # Module file doesn't need coverage instrumentation because module files
       # represent interfaces rather than implementations.
-      command = "$cxx -MD -MF $depfile {{defines}} {{include_dirs}} {{cflags}} {{cflags_cc}}${extra_cppflags}${extra_cxxflags} {{module_deps_no_self}} -fmodule-name={{cc_module_name}} -x c++ -Xclang -emit-module -c {{source}} -o {{output}}"
+      command = "$cxx -MD -MF $depfile {{defines}} {{include_dirs}} {{cflags}} {{cflags_cc}}${extra_cppflags}${extra_cxxflags} {{module_deps_no_self}} -fmodule-name={{label_name}} -x c++ -Xclang -emit-module -c {{source}} -o {{output}}"
       depsformat = "gcc"
       description = "CXX_MODULE {{output}}"
       outputs = [ "$object_subdir/{{source_name_part}}.pcm" ]

```

I thought I'd post it here because I wondered why this only hit downstream, not in your buildbots? Or is there anything wrong with my config/setup after all?

Any feedback is appreciated.

Thanks!

[1]: https://github.com/pypdfium2-team/pypdfium2/compare/6082a1ca8e79ce3663150afe5891f113306fa64b...5be6bf77a2c0973e1c745592e96c85f4feb1c6c7

[2]: https://pdfium.googlesource.com/pdfium/+/0464426e8e6a1fe45a23ad01cfcd9ddc28373d50

[3]: https://chromium.googlesource.com/chromium/src/build.git/+/17cb503758e2be337c9f2273ade0a25962ba7991

[geisserml]

Took a look at [4] (the Gerrit review page of [3]).

It seems that I'm not the only one who encountered this issue, and it is said to be simply caused by outdated GN.

I had built GN from source some time ago and had thought it not-that-outdated, but nevermind. I shall update GN locally to confirm if that makes the issue disappear.

However, we would probably still have to keep the patch because our build scripts need to remain compatible with Linux distro's builds of GN from the containers we use (and for downstream users as well).

[4]: https://chromium-review.googlesource.com/c/chromium/src/+/7593779

[geisserml]

Ok, yeah, I can confirm updating GN helps.

[Lei Zhang]

Thanks for investigating. [5] is another recent example where a
slightly out of date GN binary caused the build to fail. PDFium
developers build with the bundled GN that depot_tools look for inside
//buildtools. That version is pinned in //DEPS and should always be
correct. Issues like yours can happen in the developer's local build
when the entries in //DEPS get updated, if `build_revision` gets
updated before `gn_version`. But such a change will not pass the try
bots and actually be committed.

I don't have good answers for how Linux distros should deal with
breaking GN changes like this. Maybe ask on gn-dev@? [6]

[5] https://groups.google.com/a/chromium.org/g/chromium-dev/c/fLOf-6K85vI
[6] https://groups.google.com/a/chromium.org/g/gn-dev

> --
> You received this message because you are subscribed to the Google Groups "pdfium" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pdfium+un...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/pdfium/13fe5d76-2265-4a98-acc1-0796b697f9d3n%40googlegroups.com.