I'm fine with this as a temporary measure but I'd like to understand the plan to get us into a place where there is only one definition of each build config (aka out directory).

I'm fine with this as a temporary measure but I'd like to understand the plan to get us into a place where there is only one definition of each build config (aka out directory).

There are a few different ways to accomplish that that we'll need to discuss. I would like to consider approaches where the exact contents and layout of out/ is an implementation detail of et and CI, and in which human readable descriptions of the build configs provide a good guide for which config a developer needs at any time. (If you need to know the fine-grained details, that could be an et query subcommand.) As an example, if we choose to use the GN toolchain feature to build multiple configurations as part of the same ninja build as I've heard a few folks discuss, then the output for some build configurations would shift from the top-level out/ directory into a subdirectory 2-3 layers deep. The user shouldn't have to worry about that.

I think maybe the spirit of your question is not exactly about the out/ directory, though, but more about having a one-to-one mapping between configurations and names. If/when we design a configuration language for generating the .json files instead of hand-coding them, we should ensure that we get that one-to-one property by construction. But exactly how to do that, I don't have a detailed design for.