How to work around a config takes an action generated file as input?

[Zequan Wu]

Hi all,

I'm not sure if this is the correct place to post this. I guess I can get help/feedbacks from some gn experts.

We want to experiment building chrome with libc++ clang modules crbug.com/1430964 and add a gn arg (use_libcxx_module_experimental) to switch it. 

When this arg is true, add module related compiler flags in //build/config/c++:runtime_library. One of added compiler flag -fmodule-map-file= takes a module map file as input, which can only be generated using a python script. So, we need an action to generate it. In order to make sure the module map file is always generated when -fmodule-map-file is used, I changed //build/config/compiler:runtime_library from a config to a group that depends the action. Thus I need to remove //build/config/compiler:runtime_library from default_compiler_configs and added a default_compiler_deps as a dependency for targets uses default_compiler_configs.

`default_compiler_deps = [ "//build/config/compiler:runtime_library" ]` 

But that causes an issue that most targets add dependencies using "dep = [...]" rather than "dep += [...]" and dep now has a default default_compiler_deps, so gn complains about:

```

ERROR at //tools/aggregation_service/BUILD.gn:16:3: Replacing nonempty list.
  deps = [
  ^---

```

And by just searching "dep =" in BUILD.gn and *.gni files, it shows that there are 12000+ matches. It looks like unrealistic to change all of them to "dep +=" as that would requires lots of reviewers. 

So, my question is that is there any other ways to have a config depends on an action?

Another simple solution I could think about is to use exec_script as an action, which is undesired. 

demo cl: https://chromium-review.googlesource.com/c/chromium/src/+/4657358

[Brett Wilson]

No, configs can not affect the dependency tree.

For testing, look at the deps of the toolchain definition. This will inject the dependency into all actions for things in the toolchain.

However, I would recommend against this for real usage as its representation in .ninja files is inefficient. If you want to enable it by default, I would do some careful study of .ninja file bloat and null build performance.

Brett

[Zequan Wu]

  However, I would recommend against this for real usage as its representation in .ninja files is inefficient. If you want to enable it by default, I would do some careful study of .ninja file bloat and null build performance.

Will this kind of representation inefficiency cause slowing down the build process? Maybe it's something that needs to be improved in gn to generate more efficient ninja files? Or is it just the nature of ninja in handling this kind of dependency?

[Brett Wilson]

On Thu, Jun 29, 2023 at 1:34 PM Zequan Wu <zequ...@google.com> wrote:

  However, I would recommend against this for real usage as its representation in .ninja files is inefficient. If you want to enable it by default, I would do some careful study of .ninja file bloat and null build performance.

Will this kind of representation inefficiency cause slowing down the build process? Maybe it's something that needs to be improved in gn to generate more efficient ninja files? Or is it just the nature of ninja in handling this kind of dependency?

It will slow down the parsing of the Ninja files. This will be most noticeable in the null build time which is why I mentioned measuring that.

It's been a while but I would guess the representation can be improved somewhat. But the whole point is that this is adding a dependency for every single build action, so it will never be free.

Brett