Open nyanpasu64 opened 6 years ago
I tried running a build in Visual Studio with CLCACHE_CL set. The build never started (I'm not sure if CLCACHE_CL was passed into clcache.exe properly) complained CL.exe path was too long (must be below 260 characters or something). Ctrl-F through Diagnostic logs showed that error was the only occurrence of cl.exe
(it never got called).
In [5]: from pathlib import Path
In [13]: Path('/users/jimbo1qaz/path').resolve()
Out[13]: WindowsPath('C:/Users/jimbo1qaz/Dropbox/encrypted/dirlinks/path')
In [14]: Path('/users/jimbo1qaz/path').resolve() == Path('/users/jimbo1qaz/dropbox/encrypted/dirlinks/path').resolve()
Out[14]: True
In [15]: Path('/users/jimbo1qaz/path') == Path('/users/jimbo1qaz/dropbox/encrypted/dirlinks/path')
Out[15]: False
In [16]: Path('/users') == Path('/Users')
Out[16]: True
In [17]: os.path.realpath('/users') == os.path.realpath('/userS')
Out[17]: False
Pathlib was introduced in 3.4. Apparently you've dropped Python 3.3 and 2.x already.
Path(_).resolve()
, os.path.splitext(_)[0]
, Path(_)
) != Path(sys.argv[0]).resolve().
I'd send a pull request, but this project seems unmaintained.
I have quite a complex setup, with a "path" folder stored under %userprofile%/Dropbox/encrypted/dirlinks/path, and symlinked to %userprofile%/encrypted/dirlinks/path and %userprofile%/path. I also have ConEmu installed.
I only added
%userprofile%/path
to my PATH variable, while building in Visual Studio.When I copy clcache.exe to
cl.exe
and execute it, it enters infinite recursion, unless:path
folder, and not a path to that folder, but containing symlinks along the way.If 2 is not true,
findCompilerBinary()
returns the wrong path sincemyExecutablePath()
(sys.executable.upper()) differs frompath.upper()
(from %PATH%), even if cl.exe is the same file, accessed via different symlinks.If 1 is not true, I don't know what's wrong since I don't know how to debug py2exe programs.
I could set
CLCACHE_CL
, but the default folder differs by host and EXE architecture, making me feel somewhat uncomfortable about setting it up (hard-coded to match one VS project and configuration).Maybe you should use os.path.realpath(...) or Path.resolve() to normalize paths, to fix 2. I'm not sure if that will fix 1.