Should further environment variables be overridable?

[madsmtm]

Some environment variables are overridable with Build::env, see #1682 for the implementation. We were quite conservative in which environment variables we allow overriding, currently only:

• SDKROOT
• *_DEPLOYMENT_TARGET
• WASI_SDK_PATH

But maybe we should allow overriding further things? See #1656 (comment) for discussion on different "categories" of environment variables, especially category 2 is interesting.

(Or maybe we shouldn't allow overriding anything at all? Would be slightly breaking to walk back on it, but depending on when we do so, people might not be aren't relying on it?)

[justsmth]

FYI -- just for awareness, no action needed. The recent behavior changes in cc potentially breaks the build of aws-lc-sys for consumers that have optimization flags set in their CFLAGS environment variable. I posted a PR to address it in aws-lc-sys: aws/aws-lc-rs#1064

[NobodyXu]

Thanks for update!

Given that env var setting is unsafe, I was wondering if we should make it possible to not read from env/skip some flags from env

[justsmth]

Given that env var setting is unsafe, I was wondering if we should make it possible to not read from env/skip some flags from env

I think the current behavior (env CFLAGS taking higher precedence than Build::flag) is the right default -- it ensures consumers can always override flags set by build scripts. The situation where C code can't tolerate certain env flags (like jitter-entropy requiring -O0) is rare.

For aws-lc-sys, we resolved this by stripping conflicting optimization flags from CFLAGS before calling compile_intermediates() -- so set_var is scoped tightly and only runs in the build script (where thread-safety of env mutation is manageable).

Adding something like Build::ignore_env_var("CFLAGS") might cause more harm than good -- it could encourage build scripts to broadly ignore important environment variables that consumers need. I'd rather keep the workaround on our side than introduce an API that's easy to misuse.