I think this is working like any other import, but the semantics of import doesn't allow what you're trying to do. You want C #include semantics where the included file is executed in the context of the caller and can change its state. GN imports are designed to be executed once in an independent context.

So this won't work for cases where you want to change the current_os or something. In your case you just need to inline the code.

I also realized late yesterday that you should *never* import anything from BUILDCONFIG even if you were happy with the current semantics (contrary to my previous advice). I filed issue 828454 which explains the problem.

So, how do one go about "inlining the code"?

I see 3 options:

* import() works as an inline in BUILDCONFIG, that is, it read from the file and inserted verbatim in the embedding file, and the parser continue parsing from there.

* or, a new function, e.g. "inline" or "include", implement the above (main issue with both is how to limit the operation to build configs)

* or, my suggestion of specifying multiple build config files that are concatenated into a single file and then parsed. <https://chromium-review.googlesource.com/c/chromium/src/+/979443>

Add your code to the bottom of the file. As I said, you're welcome to add an annotation at the bottom so you're guaranteed to not have merge conflicts for these additions.

What you are effectively saying, is that NO embedder of Chromium can *ever* create their own BUILDCONFIG file, unless they copy verbatim everything from your file. Even if they never change a single bit in any other file, they have to branch the chromium code in order to make any build config changes they need to include.

The build is designed to be configured via GN args.

The variables settings in our case includes adding default configs for compiler, linker, etc.

AFAIK those cannot be set via GN args, nor can they be updated later as I understand the documentation.

The chromium build is not designed to be used by embedders to have their own BUILDCONFIG files so, yes, that's accurate. Whether we *ever* allow something is up for discussion in bug 828454 +/- the levels of semantics and confusion.

I don't think forking the BUILDCONFIG file and having to maintain a patched version is a hard thing to do in the meantime. brettw@ has even discussed how we can make that easier for you.

Well, in our case we are using the GN extension referenced above, so that is not really a problem for us. But other embedders might find this to be a small irritation.

IMO, since this is a project used by others (AFAICT such use is encouraged), then you should accommodate reasonable downstream use and expectations by embedders. I think that being able to have custom BUILDCONFIGs that import/inline the normal chromium build config is a very reasonable expectation.

We use the extension mentioned because we were not able to use the chromium build config the natural way (an import).