Skip to content

Add CC_PREFER_CLANG_CL_OVER_MSVC environment variable to override prefer_clang_cl_over_msvc#1675

Open
ArchangelX360 wants to merge 1 commit intorust-lang:mainfrom
ArchangelX360:archangelx360/override_prefer_clang_cl_by_env
Open

Add CC_PREFER_CLANG_CL_OVER_MSVC environment variable to override prefer_clang_cl_over_msvc#1675
ArchangelX360 wants to merge 1 commit intorust-lang:mainfrom
ArchangelX360:archangelx360/override_prefer_clang_cl_by_env

Conversation

@ArchangelX360
Copy link
Contributor

Fixes #1673

@ArchangelX360 ArchangelX360 force-pushed the archangelx360/override_prefer_clang_cl_by_env branch 2 times, most recently from 2372f80 to f1c838e Compare February 11, 2026 19:15

const CC_PREFER_CLANG_CL_OVER_MSVC_ENV_VAR: &str = "CC_PREFER_CLANG_CL_OVER_MSVC";
fn get_prefer_clang_cl_over_msvc_from_env() -> Option<bool> {
#[allow(clippy::disallowed_methods)]
Copy link
Contributor Author

@ArchangelX360 ArchangelX360 Feb 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understood correclty, getenv or getenv_boolean won't default to the host environment, so it's not applicable to us here as we actually want to have the host environment leak to us if I'm not mistaken.

However, how can I test that? Because tests are run in parallel, so in my current test implementation it just does not work as tests are leaking that env to one another most probably.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See tests/cc_env.rs

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks I'll implement it that way for now.

Then we can discuss the following here: would it be an acceptable design for you to always propagate CC_PREFER_CLANG_CL_OVER_MSVC to self.env in the Build::new constructor?

There is two advantages to that:

  • I don't have to use the main function trick in tests and rely on setting self.env
  • I can use self.getenv_boolean in the implementation of Build

CC_FORCE_DISABLE would be under the same regime too, for example.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not entirely sure I understand the question, but you might wanna wait for #1656 before making too many bold changes to how environment variables work?

src/lib.rs Outdated
build_cache: Arc::default(),
inherit_rustflags: true,
prefer_clang_cl_over_msvc: false,
prefer_clang_cl_over_msvc: get_prefer_clang_cl_over_msvc_from_env().unwrap_or(false),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'd prefer to do things at the usage site instead, something like:

let prefer_clang_cl_over_msvc_env = self.getenv_boolean("CC_PREFER_CLANG_CL_OVER_MSVC");
let msvc = if prefer_clang_cl_over_msvc_env.unwrap_or(self.prefer_clang_cl_over_msvc) {
    "clang-cl.exe"
} else {
    "cl.exe"
};

@ArchangelX360 ArchangelX360 force-pushed the archangelx360/override_prefer_clang_cl_by_env branch 2 times, most recently from 6d7cbf4 to 24d85f2 Compare February 11, 2026 23:49
@ArchangelX360 ArchangelX360 force-pushed the archangelx360/override_prefer_clang_cl_by_env branch from 24d85f2 to 5ef66da Compare February 11, 2026 23:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

prefer_clang_cl_over_msvc is only tweakable from crates directly using cc-rs

2 participants