Skip to content

Conversation

@jcbrill
Copy link
Contributor

@jcbrill jcbrill commented Aug 13, 2025

The list of variables imported from the OS environment and added to the msvc environment was moved from inside a function to file-level in #4717 which could enable a user to extend the list of imported variables. This could yield unexpected behavior with the msvc runtime and/or external file cache.

The msvc cache key consists of the msvc batch file and the msvc batch file arguments. The cache contents are based on both the list of variables imported from the OS environment and the list of variables preserved from the msvc environment. Additions to the list of variables imported from the OS environment could introduce runtime and/or external file cache consistency issues. Under certain circumstances, due to runtime and/or external file caching, additions to the list of variables imported from the OS environment could be ignored entirely.

The tuple of variables retrieved from the msvc environment and added to the SCons environment is defined at file-level. The tuple of variables is specified as the default value of an argument in the function to process the msvc output. The optional argument is not passed from the vc code. As written, it is effectively impossible to extend the tuple of preserved variables and have the extended variables used within the function to process the msvc output.

The variables imported from the OS environment was changed from a list to a tuple.

The tuple of variables imported from the OS environment and added to the msvc environment is defined at file-level. The tuple of variables is now specified as the default value of an argument in the function to get the msvc output. The optional argument is not passed from the vc code. As written, it is effectively impossible to extend the tuple of imported variables and have the extended variables used within the function to get the msvc output.

This PR effectively restores the behavior of the imported and preserved variables list behavior to the behavior prior to acceptance of #4717 until the cache consistency issues can be addressed.

There may be some relevant discussion in #4727 which was abandoned.

This PR is internal only with nothing user-facing.

Contributor Checklist:

  • I have created a new test or updated the unit tests to cover the new/changed functionality.
  • I have updated CHANGES.txt and RELEASE.txt (and read the README.rst).
  • I have updated the appropriate documentation

…event using runtime modified values

Changes:
- Rename VS_VC_VARS to _MSVC_ENVIRON_IMPORT.
- Rename KEEPLIST to _MSVC_ENVIRON_PRESERVE.
- Change imported variables from a list to a tuple.
- Change file level variable reference in get_output function to optional import_vars argument default value.
- rename optional keep argument in parse_output function to keep_vars.
- Update comments.
@bdbaddog
Copy link
Contributor

bdbaddog commented Sep 7, 2025

@jcbrill - so if I understand this PR the idea is to block users ability to reach in and tweak internals on the chance that doing so may yield incorrect msvc cache?
This is the flexibility we requested to fix an actual users issue right?

@jcbrill
Copy link
Contributor Author

jcbrill commented Sep 7, 2025

so if I understand this PR the idea is to block users ability to reach in and tweak internals on the chance that doing so may yield incorrect msvc cache?

Correct (more or less).

The setup configuration returned to the user may not take into account the user's changes based on the runtime and/or filesystem cache.

This is the flexibility we requested to fix an actual users issue right?

No.

The potential issue is caused by the request (starting at #4717 (comment)) to move the list of variables that was defined inside a function to file level.

Prior to the move, it was impossible for a user to modify the list of variables. The variable list move was not the result of needed functionality or user request.

This is one of those issues that makes the msvc code difficult to comprehend. What seems to be innocuous has very subtle interactions with the existing code.

There were similar issues (which have been since been fixed) with the original implementation of the VSWHERE construction variable and bypassing internally cached values.

Until a reasonable solution for cache-consistency (runtime and filesystem) is found, it better just to disallow it for now.

@bdbaddog
Copy link
Contributor

bdbaddog commented Sep 7, 2025

I disagree.

If you're monkey patching an internal variable, buyer beware.

Add a big comment near the list in the source code that if you change this list you should remove your existing msvc cache file, and call it a day.

It's not like we're documenting this usage, or providing a documented API to change this, this is reaching into the internals.

If we were, then 100% we should insure that usage by users couldn't cause the inconsistencies you're concerned about.
But we're not.

@jcbrill
Copy link
Contributor Author

jcbrill commented Sep 7, 2025

Then I guess there is no need for this PR. Closing soon.

@bdbaddog
Copy link
Contributor

bdbaddog commented Sep 7, 2025

Closing.

@bdbaddog bdbaddog closed this Sep 7, 2025
@jcbrill jcbrill deleted the jbrill-mscommon-evars branch September 7, 2025 23:05
@mwichmann mwichmann added the MSVC Microsoft Visual C++ Support label Sep 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

MSVC Microsoft Visual C++ Support

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants