Thank you Brad. I took the aggressive way and completely wiped the environment 
inside the debugged process. For those anyone wishing to do something similar, 
here’s what I’ve done:

I wrote a PowerShell oneliner:

        gci Env: | foreach { $_.Name + "=" + $_.Value } | Out-File -FilePath 
.\Desktop\env.txt -Append

When invoked inside a Visual Command Prompt this outputs a complete environment 
into a file in a format that can be copy-pasted into the Visual Studio Project 
Property Page. Make sure to set Merge Environment option to No. After this it 
worked like a charm.

Now it’s only up to me to understand the entire process of Makefile generation. 
Global/Local Generators, LocalMakeFileGenerator3 (does 3 correspond to the 
third layer of makefiles? If yes, where is 2?)… The code is fairly convoluted 
(seems a bit more complex than neccessary, but it might be my lack of 
understanding that makes me feel this way).

One sidequestion: what is the reason for eliding STL algorithms? There are nice 
iterators all over the place, yet no algorithms used, even when it were 
possible. Algorithms make the code much easier to understand (the name of the 
algorithm states the intent of the for-loop), plus when C++17 hits 
(configure-time check?), parallel STL invocations could speed up the 
configuration process automatically with minimal code impact. Would you accept 
such patches, where loops are exchanged for algorithms where possible?

Feladó: Brad King

Powered by

Please keep messages on-topic and check the CMake FAQ at:

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support:
CMake Consulting:
CMake Training Courses:

Visit other Kitware open-source projects at

Follow this link to subscribe/unsubscribe:

Reply via email to