Page MenuHomePhabricator

[lit] Pass more environment variables through on Windows
ClosedPublic

Authored by zturner on Nov 27 2018, 11:08 AM.

Details

Summary

This arose when I was trying to have a substitution which invoked a python script P, and that python script tried to invoke clang-cl (or even cl). Since we invoke P with a custom environment, it doesn't inherit the environment of the parent, and then when we go to invoke clang-cl, it's unable to find the MSVC installation directory. There were many more I could have passed through which are set by vcvarsall, but I tried to keep it simple and only pass through the important ones.

Diff Detail

Repository
rL LLVM

Event Timeline

zturner created this revision.Nov 27 2018, 11:08 AM
rnk accepted this revision.Nov 27 2018, 11:13 AM

lgtm, seems like a simplification. I guess the behavior change is that now we don't have empty INCLUDE etc variables hanging around in the environment?

This revision is now accepted and ready to land.Nov 27 2018, 11:13 AM

I don't think that ever actually happened, or at least I never observed it. The real behavior change is that we're now passing through "LIB", "VCINSTALLDIR", "VCToolsInstallDir", "VSINSTALLDIR", "WindowsSdkDir", and "WindowsSdkVersion", whereas before we were not propagating them into the child environment at all. clang-cl reads these, so it could have an observable impact on clang-cl (but any observable impact should be beneficial, since before it would actually just fail if a test tried to include a system header or link against a system library)

This revision was automatically updated to reflect the committed changes.

I don't think that ever actually happened, or at least I never observed it. The real behavior change is that we're now passing through "LIB", "VCINSTALLDIR", "VCToolsInstallDir", "VSINSTALLDIR", "WindowsSdkDir", and "WindowsSdkVersion", whereas before we were not propagating them into the child environment at all. clang-cl reads these, so it could have an observable impact on clang-cl (but any observable impact should be beneficial, since before it would actually just fail if a test tried to include a system header or link against a system library)

At least for clang tests, tests reading system libraries are usually a bug -- tests are supposed to be hermetic, cross-platform, etc. It sounds like now it's easier to accidentally use a system header?

andrewng added inline comments.
llvm/trunk/utils/lit/lit/TestingConfig.py
37

Was the change from PYTHONUNBUFFERED to PYTHONBUFFERED intentional? AFAIK PYTHONBUFFERED is not an environment variable recognised by Python.

Herald added a project: Restricted Project. · View Herald TranscriptJul 15 2019, 6:32 AM