[cmake-developers] Debug through config/gen inside Visual Studio
Hi everyone! I wanted to see how CMake actually Works under the covers to see how much actual work it would take to implement a feature I proposed quite a while ago. My problem is that even though I built CMake with the „Visual Studio 14 2015 Win64” generator, I setup the cmake target to use: Command Arguments: -G "NMake Makefiles" C:\Users\Matty\OneDrive\Develop\Tests\CMake\CMake_example Working Directory: C:\Users\Matty\Build\CMake_Example\NMake There is even an option to create new environtment variables prior to debugging. My problem is that even though I checked what vcvarsall.bat creates on the command line, I exported the same variables, but the compiler fails according to CMake (see at the end). How do you setup Visual Studio to debug through a config/gen process? Thanks in advance, Máté -- The C compiler identification is MSVC 19.0.24213.1 -- The CXX compiler identification is MSVC 19.0.24213.1 -- Check for working C compiler: C:/Kellekek/Microsoft/Visual Studio/14.0/VC/bin/amd64/cl.exe -- Check for working C compiler: C:/Kellekek/Microsoft/Visual Studio/14.0/VC/bin/amd64/cl.exe -- broken CMake Error at C:/Users/Matty/Source/Repos/CMake/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "C:/Kellekek/Microsoft/Visual Studio/14.0/VC/bin/amd64/cl.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: C:/Users/Matty/Build/CMake_Example/NMake/CMakeFiles/CMakeTmp Run Build Command:"nmake" "/NOLOGO" "cmTC_064d4\fast" "C:\Kellekek\Microsoft\Visual Studio\14.0\VC\bin\amd64\nmake.exe" -f CMakeFiles\cmTC_064d4.dir\build.make /nologo -L CMakeFiles\cmTC_064d4.dir\build Building C object CMakeFiles/cmTC_064d4.dir/testCCompiler.c.obj C:\Kellekek\MICROS~1\VISUAL~1\14.0\VC\bin\amd64\cl.exe @C:\Users\Matty\AppData\Local\Temp\nmBF98.tmp testCCompiler.c Linking C executable cmTC_064d4.exe C:\Users\Matty\Build\CMake\VS14\bin\Debug\cmake.exe -E vs_link_exe --intdir=CMakeFiles\cmTC_064d4.dir --manifests -- C:\Kellekek\MICROS~1\VISUAL~1\14.0\VC\bin\amd64\link.exe /nologo @CMakeFiles\cmTC_064d4.dir\objects1.rsp @C:\Users\Matty\AppData\Local\Temp\nmC1FA.tmp RC Pass 1 failed to run. NMAKE : fatal error U1077: 'C:\Users\Matty\Build\CMake\VS14\bin\Debug\cmake.exe' : return code '0x' Stop. NMAKE : fatal error U1077: '"C:\Kellekek\Microsoft\Visual Studio\14.0\VC\bin\amd64\nmake.exe"' : return code '0x2' Stop. CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:5 (project) -- Configuring incomplete, errors occurred! See also "C:/Users/Matty/Build/CMake_Example/NMake/CMakeFiles/CMakeOutput.log". See also "C:/Users/Matty/Build/CMake_Example/NMake/CMakeFiles/CMakeError.log". Press any key to continue . . . -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Debug through config/gen inside Visual Studio
Apologies, there is one important moment I failed mention. If I do not set any env vars for the debugger, cmake still finds cl.exe with the „NMake Makefiles” generator, which clearly states that it is not a clean user environment I get inside the debugger. Feladó: csiga.b...@aol.com-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Debug through config/gen inside Visual Studio
Some very interesting things are happening. I am walking through the code with F11, F10, Shift+F10 and trying to understand what’s happening. What really makes this process hard is that occasionally it succeeds generating the Makefile and the exit code is 0. Ultimately if I try to run the generated makefile it terminates with a linker error: PS C:\Users\Matty> Import-VisualEnvironment -Version 14 -Architecture Win64 PS C:\Users\Matty> cl.exe Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x64 Copyright (C) Microsoft Corporation. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ] PS C:\Users\Matty> cd .\Build\CMake_Example\NMake\ PS C:\Users\Matty\Build\CMake_Example\NMake> nmake clean Microsoft (R) Program Maintenance Utility Version 14.00.24210.0 Copyright (C) Microsoft Corporation. All rights reserved. PS C:\Users\Matty\Build\CMake_Example\NMake> nmake Microsoft (R) Program Maintenance Utility Version 14.00.24210.0 Copyright (C) Microsoft Corporation. All rights reserved. [ 20%] Building CXX object phys/CMakeFiles/Phys.dir/src/stuff.cpp.obj stuff.cpp [ 40%] Building CXX object phys/CMakeFiles/Phys.dir/src/more.cpp.obj more.cpp [ 60%] Linking CXX static library Phys.lib [ 60%] Built target Phys [ 80%] Building CXX object app/CMakeFiles/Application.dir/src/main.cpp.obj main.cpp [100%] Linking CXX executable Application.exe [100%] Built target Application Import-VisualEnvironment is a PowerShell Commandlet made by me which essentially calls vcvarsall.bat. The extra info I gained through the VERBOSE=1 env var is this: Linking C executable cmTC_14330.exe C:\Users\Matty\Build\CMake\VS14\bin\Debug\cmake.exe -E vs_link_exe --intdir=CMakeFiles\cmTC_14330.dir --manifests -- C:\Kellekek\MICROS~1\VISUAL~1\14.0\VC\bin\amd64\link.exe /nologo @CMakeFiles\cmTC_14330.dir\objects1.rsp @C:\Users\Matty\AppData\Local\Temp\nm32CF.tmp Visual Studio Incremental Link with embedded manifests Create CMakeFiles\cmTC_14330.dir/manifest.rc Create empty: CMakeFiles\cmTC_14330.dir/embed.manifest RC Pass 1: /foCMakeFiles\cmTC_14330.dir/manifest.res CMakeFiles\cmTC_14330.dir/manifest.rc RC Pass 1 failed to run. However, this part I do not understand. I believe something is not quite consistent within the generation process, sometimes succeeding and somethimes not. Any ideas? Thanks Brad for the tips thus far, Máté Feladó: Brad King Elküldve: 2016. szeptember 15., csütörtök 15:11 Címzett: csiga.b...@aol.com Másolatot kap: cmake-developers@cmake.org Tárgy: Re: [cmake-developers] Debug through config/gen inside Visual Studio On 09/15/2016 09:04 AM, csiga.b...@aol.com wrote: > That is exactly what I’m doing. I am generating a VS solution, and > inside that I setup the debugging environment, but the process I want > to debug is not the VS solution generation, but the NMake Makefile > generation process. Okay, misread your original message. I've never actually tried that. > What should I put inside the Environment dialog to make things work? > Even when it’s empty, it finds cl.exe, but cmake fails trying to use it. Add "VERBOSE=1" to the environment to get a little more output about the "RC Pass 1 failed to run" failure. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Debug through config/gen inside Visual Studio
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 www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Discussion] Add python support forCMakeLists
This all rhymes fairly well with an earlier suggestion of mine, CMake IR, a stateless intermediate representation. Though I originally suggested this feature to facilitate the authoring of generators, it could’ve also act as an alternative front-end, other than the CMake script language (which is still the least friendliest part in CMake, hence these attempts of ridding it in favor of friendlier scripting languages). The scenario depicted here is pretty much doable already, but not in CMake terms. The stateless part is pretty much MSBuild, built atop XML with well defined schemas for the various build steps (C++ build, C++ link, C# build, etc.), and there is a custom target that has pre-build, build, and post-build steps (as all other targets as well). If you’d invoke Python there, you’re pretty much at the place you depict here. Using MSBuild, you’d only need a schema to invoke CMake targets to interoperate with current CMake projects. One of the reasons why VS is so successful, is because you don’t need to invoke voodoo to acomplish something as simple as a build. Click-click and you’re done. This is because the build representation is SIMPLE (just XML). I understand that the reason why CMakes script language only has one type, the string type is because it is the common denominator for all the target generators and it is easy to handle inside generator implementations, but heck, it’s a pain to use. The fact that source files to add_executable() may be a list, but target_compile_definitions cannot… it’s a joke. I have to manually insert spaces in between compiler options. Apologies if my tone is harsh at times, but I believe CMake could do a lot better. Server Mode is welcome sight, but it’s pretty much a workaround, or at least half the job. I believe CMake really needs to open to other front-ends than its script language, and Server Mode only compliments this. I understand that it becomes an N*M issue at this point, but heck; we have lived with containers and iterators (abstractions in general) that go around this issue. MSBuild going cross-platform thanks to .Net Core renders it a compelling alternative for everyday tasks. (And I still have not touched upon Scons, Cake, Fake, Psbuild and the likes.) Feladó: Shmuel H, Elküldve: 2017. január 14., szombat 9:27 Címzett: Brad King Másolatot kap: CMake Developers Tárgy: Re: [cmake-developers] [Discussion] Add python support forCMakeLists Maybe we could combine them together: the configuration process would be separated into two stages: 1. Script stage: Look for and run build script, that will generate a [JSON] configuration file. 2. Look for a configuration file, and generate build files according to it. Then, a programmer should decide if he need to use the script stage. If not, he would be able to edit it all with its favorite IDE. If he need the script stage, he would not be able to edit it with a automatic tools. I think we should make the configuration files as simple as we can (`cbp` files are not a good example for a simple file): usable defaults for fields, etc. Adding named condition \ variables would serve only a part of developers needs (for example, choosing source files according to the current OS) but it would prevent developers from being able to customize their building with functions (For example, applying a long set of configurations for each build target to be used as a plugin for an application with a lot of restrictions). On Fri, Jan 13, 2017 at 9:28 PM, Brad King wrote: On 01/13/2017 11:45 AM, Shmuel H, wrote: > * From the other side, programmers should be able to use a script > language to customize their build process. > > For example, a simple declaration (pseudo code): > cmake_libraries += { > ["name": "myLib", > "files": "myLib.c", > "link_type": "static"] > } The declarative part needs to be self-standing so that it can be loaded by an IDE, edited by the user, and saved back out in the original format with a minimal diff. An IDE will have no idea how to write snippets back into a procedural script. This is one reason CMakeLists.txt files cannot be edited through an IDE except as text files. My proposal is that the declarative part would have most of the build, but with some kind of named condition/config variables. Then the procedural part will introspect the system to determine the values of the configuration variables so that CMake can evaluate the conditions. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html C
Re: [cmake-developers] [CMake] [MSVC] Setting warning level on target feels like long-time bug
I was just about to write a mail with similar content than this one, so allow me to add my 5 cents. Fear of reyling on defaults in case Microsoft decides to change them? 1) Defaults don't change often. BTW, don't we rely on defaults for GCC and Clang anyway?2) Defaults change to benefit users. If the default changes from /W3 to /W4 per say, it would be because windows.h headers and the STL would be cleaned up for the warnings in /W4 and MS felt that it would be better if users relied on all the warning they packed there. (Currently it is not the case) As for having to call string() on CMAKE_CXX_FLAGS to up my warning level for a single compiler... these sort of idiosincrecies are the ones that drive people away from CMake to Meson and other, more modern build systems. Not being able to clean up decades worth of sediments in script style will result in CMake's demise. if (MSVC) string(REGEX REPLACE "/W[0-9]""" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})endif (MSVC) add_executable(${PROJECT_NAME}main.cpp) target_compile_options(${PROJECT_NAME}PRIVATE$<$,$>:-Wall-Wextra -pedantic> $<$:/W4>) Instead of add_executable(${PROJECT_NAME}main.cpp) target_compile_options(${PROJECT_NAME}PRIVATE$<$,$>:-Wall-Wextra -pedantic> $<$:/W4>) Or even add_executable(${PROJECT_NAME}main.cpp) set_target_properties(${PROJECT_NAME}PROPERTIES WARNING_LEVEL HIGH) is nonsense. There should be direct support for a few pre-defined, commonly accepted warning levels. If not this, having to explain to C++ freshmen why we're running regexes over lists default args to clean them up BEFORE even stating our bussiness... Please, remove this default because it hurts CMake as a whole. Cheers,Máté -Original Message- From: Mateusz Loskot To: marc.chevrier Cc: cmake-developers ; cmake Sent: Sun, Dec 9, 2018 2:55 pm Subject: Re: [cmake-developers] [CMake] [MSVC] Setting warning level on target feels like long-time bug On Sun, 9 Dec 2018 at 14:09, Marc CHEVRIER wrote: > > I think the discussion is shifting from the initial problem which was > unwanted warning « Command line warning D9025: overriding '/W3' with '/W4' ». I disagree with your opinion. Fixing just the warning would be a symptomatic treatment. > Changing defaults is not a good idea from my point of view because relying on > defaults can be problematic if Microsoft decide to change the default > behaviour. Although I think it is a long shot at something that is (highly) unlikely to change, YAGNI consideration, I understand CMake developers may be reluctant to change the long-time defaults. > The real question is how to manage cleanly target specific flags overriding > global or directory defaults? >From end-user point of view (I have not checekd CMake implementation), I'd either do not explicitly set -W defaults or strip any -W option prior re-setting with (possibly) new value passed to target_compile_options. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers