Right now, ARC compilation for the Mac is a config, “//build/config/compiler:enable_arc”. It’s enabled for ~800 targets
, and not enabled for 5 targets. That’s an understandable result of an incremental migration, but a bad situation to be in; for something that prevalent, we want to have it enabled globally and disabled for the handful of targets that don’t want it. That’s the situation that I want to end up at.
Plan A: Step 1: In a CL, add “enable_arc” to build/config/BUILDCONFIG.gn’s default_compiler_configs, and in 5 targets remove it. Step 2: take time to go through all the 800 targets that explicitly add “enable_arc”, and remove it as it’s redundant with the global config.
That doesn’t work. GN doesn’t like when you have the same config applied twice to a target.
OK, plan B: Step 1: In a CL, create an “enable_arc2” duplicate of “enable_arc”, and add that to the default config set while subtracting it from the config set of the handful of targets that don’t want it. Step 2: remove all the “enable_arc” configs. Step 3: rename “enable_arc2” to “enable_arc”.
That would work, but there are at least four different /third_party directories whose BUILD.gn files live in external repos (/third_party/angle, /third_party/dawn, /third_party/skia, /third_party/swiftshader). They depend on /build. Therefore I would need to do a “config -= [ “enable_arc2” ]” in each of them.
But there’s a problem. Angle
, and SwiftShader
are autorolled. For each of them, I can prepare a CL in that external repo that depends on “enable_arc2” but if the roll happens before
the change in the Chromium repo lands, then the build will fail because the rolled version of the external dep will be referring to a non-existent config. If the roll happens after
the change in the Chromium repo lands, then the Chromium change will fail because we’d be building the dep in a configuration it doesn’t support. And I can’t hold up four different autorolled external dependencies
to do a coordinated commit across five repos.
While gn’s enforcement of not allowing a config to be added twice to a list is a pain that I can work around, I don’t see how to work around its enforcement of not allowing a config to be removed from a list that doesn’t contain it. I don’t see how to do large scale migrations in situations where the BUILD.gn file is deps-ed in from the outside.
Is it possible to do “remove this config from the list of configs if it exists and do nothing if not”? Is it possible to add that capability to gn, even if it’s immediately removed afterwards? What I’m doing is not unreasonable: I’m trying to make the Mac/iOS build much cleaner, and gn’s strictness seems to make it impossible to get to the cleaner future we all want.