clcache
clcache copied to clipboard
INCLUDE & LIBPATH environment variables are not respected
clcache does not respect any of the CL Environment Variables. Most notably,
CLcan be used to specify arguments to be prepended to the command line._CL_can be used to specify arguments to be appended to the command line.
I suspect INCLUDE should be honoured as well, but I'm not sure whether it overrides or is overridden by paths specified on the command line. Same goes for LIBPATH.
To move this from bug to the missing feature state, we can pass to real compiler when one of those env variables is set.
Good point! I'd just log it as a 'cache miss' without going into more detail.
However, I wonder whether it's really so difficult to support this; we already have expandCommandLine which 'expands' the command line by reading response files. I think it wouldn't be far-fetched to say that this function could also expand the command line by whatever arguments are given in CL and _CL_ (I guess they should be expanded first because they might reference response files).
INCLUDE, LIBPATH are set by the Visual Compiler installation. E.g. in vcvarsamd64_x86.bat via vcvarsall.bat:
@rem
@rem Set Windows SDK include/lib path
@rem
@if not "%WindowsSdkDir%" == "" @set PATH=%WindowsSdkDir%bin\x64;%WindowsSdkDir%bin\x86;%PATH%
@if not "%WindowsSdkDir%" == "" @set INCLUDE=%WindowsSdkDir%include\%WindowsSDKVersion%shared;%WindowsSdkDir%include\%WindowsSDKVersion%um;%WindowsSdkDir%include\%WindowsSDKVersion%winrt;%INCLUDE%
@if not "%WindowsSdkDir%" == "" @set LIB=%WindowsSdkDir%lib\%WindowsSDKLibVersion%um\x86;%LIB%
@if not "%WindowsSdkDir%" == "" @set LIBPATH=%WindowsLibPath%;%ExtensionSDKDir%\Microsoft.VCLibs\14.0\References\CommonConfiguration\neutral;%LIBPATH%
@REM Set NETFXSDK include/lib path
@if not "%NETFXSDKDir%" == "" @set INCLUDE=%NETFXSDKDir%include\um;%INCLUDE%
@if not "%NETFXSDKDir%" == "" @set LIB=%NETFXSDKDir%lib\um\x86;%LIB%
@rem
@rem Set UniversalCRT include/lib path, the default is the latest installed version.
@rem
@if not "%UCRTVersion%" == "" @set INCLUDE=%UniversalCRTSdkDir%include\%UCRTVersion%\ucrt;%INCLUDE%
@if not "%UCRTVersion%" == "" @set LIB=%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86;%LIB%
Given that, we cannot just skip the caching for those because it makes clcache useless. Right not, everything builds on the assumption, that those variables do not change.
The semantics of CL and _CL_ seem to be simple enough, but I didn't find any documentation on how INCLUDE, LIBPATH work exactly, i.e. do they override arguments on the command line or do they serve as fallbacks?
Interestingly, in the batch file you quote, there's also LIB visible in addition to LIBPATH. I think clcache does not need to care about that though since it's part of the LINK Environment Variables.
INCLUDE must be somehow added to the /I parameters, with whatever priority.
I think we just need to hash INCLUDE into the key such that there is no hit for different INCLUDE values. This in addition to #198 should solve the bug.
Merging #203 added support for CL and _CL_.
As this stands at the moment (i.e. INCLUDE and LIBPATH only), is it true to say that clcache will work provided INCLUDE and LIBPATH never change? (But that if they do change, clcache is likely get a cache hit when it should force a miss). If so, could the README.md be clarified to say that.
@MartinBonner Indeed, if INCLUDE and LIBPATH never change, clcache ought to work just fine. The fact that these variables are not supported is already briefly mentioned in the README.md file (in the Known limitations section). Maybe it would also be nice to add a corresponding section to the Caveats page on the Wiki -- you'd be more than welcome to do so! :-)