I just started using the Clion IDE. Maybe this is written somewhere but I haven't seen it in a Google search. If I put a message() call in my CMake script, where in Clion can I see the output? These message calls are the only way that I know how to debug my CMake scripts.
Use message(WARNING ...) instead of message(...). Warnings go to stderr.
Another possible workaround:
disable "cmake auto-reload" if it is enabled
after you changed something in your cmake file, don't trigger "Reload changes"
run/build your project
When clion starts a build, it realizes the cmake files are not up-to-date and reloads them, but like other build output it is displayed inside the Messages tab.
Warning and errors are displayed, but other messages are currently suppressed. However, there is a feature request concerning this issue.
As of CLion 2016.2.2,
Build #CL-162.1967.7, CLion is displaying CMake message(STATUS) output in its Messages tool window (Alt+0) during Build (Ctrl+F9) when a project is first built after changes to CMakeLists.txt. But as noted in the other answers, this output doesn't show in CLion's CMake tool window (as many would prefer).
Update: Above I wrote that CLion "is displaying message(STATUS) output." I now find that this occurs intermittently. #Michael wrote that this happens if you skip cmake reload after modifying your cmake file, but I've found CLion sometimes does not display any CMake output in its Messages tool window even under this condition. So far I haven't discovered the exact circumstances that make CLion show CMake message(STATUS) output, will report back here when/if I do.
Big Update: CLion opens 2016.3 EAP: user-defined literals, CMake output, C11 keywords completion and more. See in particular:CMake output window: a separate I think it fixes this whole problem: CLion 2016.3 EAP adds a new tab that contains CMake command output.
Of course, this is EAP, which comes with JetBrains' caveat:
It is important to distinguish EAP from traditional pre-release
software. Please note that the quality of EAP versions may at times be
way below even usual beta standards.
So use it at your own risk, but you may judge this a risk worth taking if you need the CMake debugging.
Related
I've been using QtCreator as my CMake IDE for a long time in Ubuntu. Today I was notified there was an update. So I updated and it looks like I can't compile CMake projects anymore.
This is the error I get when I run CMake from the IDE.
error: The source directory "/tmp/QtCreator-jNrmHx/qtc-cmake-OgPpycUx" does not appear to contain CMakeLists.txt.Specify --help for usage, or press the help button on the CMake GUI.
Any ideas what could be the problem?
I had a similar issue when setting up a new build config with QtC 4.14.
In "CMake Initial parameters", make sure that there is no empty lines, and that each option is one per line. I then deleted the temp source folder re-ran CMake.
After running the cmake command once to generate a build system, when, if ever, should I rerun the cmake command?
The generated build systems can detect changes in the associated CMakeLists.txt files and behave accordingly. You can see the logic for doing so in generated Makefiles. The exact rules for when this will happen successfully are mysterious to me.
When should I rerun cmake? Does the answer depend on the generator used?
This blog post (under heading: "Invoking CMake multiple times") points out the confusion over this issue and states that the answer is actually 'never', regardless of generator, but I find that surprising. Is it true?
The answer is simple:
The cmake binary of course needs to re-run each time you make changes to any build setting, but you wont need to do it by design; hence "never" is correct regarding commands you have to issue.
The build targets created by cmake automatically include checks for each file subsequently [=starting from the main CMakeLists.txt file] involved or included generating the current set of Makefiles/VS projects/whatever. When invoking make (assuming unix here) this automatically triggers a previous execution of cmake if necessary; so your generated projects include logic to invoke cmake itself! As all command-line parameters initially passed (e.g. cmake -DCMAKE_BUILD_TYPE=RELEASE .. will be stored in the CMakeCache.txt, you dont need to re-specify any of those on subsequent invocations, which is why the projects also can just run cmake and know it still does what you intended.
Some more detail:
CMake generates book-keeping files containing all files that were involved in Makefile/Project generation, see e.g. these sample contents of my <binary-dir>/CMakeFiles/Makefile.cmake file using MSYS makefiles:
# The top level Makefile was generated from the following files:
set(CMAKE_MAKEFILE_DEPENDS
"CMakeCache.txt"
"C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/CMakeCCompiler.cmake.in"
"C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/RepositoryInfo.txt.in"
"<my external project bin dir>/release/ep_tmp/IRON-cfgcmd.txt.in"
"../CMakeFindModuleWrappers/FindBLAS.cmake"
"../CMakeFindModuleWrappers/FindLAPACK.cmake"
"../CMakeLists.txt"
"../CMakeScripts/CreateLocalConfig.cmake"
"../Config/Variables.cmake"
"../Dependencies.cmake"
"CMakeFiles/3.1.0/CMakeCCompiler.cmake"
"CMakeFiles/3.1.0/CMakeRCCompiler.cmake")
Any modification to any of these files will trigger another cmake run whenever you choose to start a build of a target. I honestly dont know how fine-grained those dependencies tracking goes in CMake, i.e. if a target will just be build if any changes somewhere else wont affect the target's compilation. I wouldn't expect it as this can get messy quite quickly, and repeated CMake runs (correctly using the Cache capabilities) are very fast anyways.
The only case where you need to re-run cmake is when you change the compiler after you started a project(MyProject); but even this case is handled by newer CMake versions automatically now (with some yelling :-)).
additional comment responding to comments:
There are cases where you will need to manually re-run cmake, and that is whenever you write your configure scripts so badly that cmake cannot possibly detect files/dependencies you're creating. A typical scenario would be that your first cmake run creates files using e.g. execute_process and you would then include them using file(GLOB ..). This is BAD style and the CMake Docs for file explicitly say
Note: We do not recommend using GLOB to collect a list of source files from your source tree. If no CMakeLists.txt file changes when a source is added or removed then the generated build system cannot know when to ask CMake to regenerate.
Btw this comment also sheds light on the above explained self-invocation by the generated build system :-)
The "proper" way to treat this kind of situations where you create source files during configure time is to use add_custom_command(OUTPUT ...), so that CMake is "aware" of a file being generated and tracks changes correctly. If for some reason you can't/won't use add_custom_command, you can still let CMake know of your file generation using the source file property GENERATED. Any source file with this flag set can be hard-coded into target source files and CMake wont complain about missing files at configure time (and expects this file to be generated some time during the (first!) cmake run.
Looking into this topic for reading the version information from a debian/changelog file (generation phase), I ran in the topic that cmake execution should be triggered as debian/changelog is modified. So I had the need to add debian/changelog to CMAKE_MAKEFILE_DEPENDS.
In my case, debian/changelog is read through execute_process. Execute_process unfortunately gives no possibility to add files processed to CMAKE_MAKEFILE_DEPENDS. But I found that running configure_file will do it. Actually I am really missing something like DEPENDENCIES in execute_process.
However, as I had the need to configure the debian/changelog file for my needs, the solution came implicitly to me.
I actually also found a hint about this in the official documentation of configure_file:
"If the input file is modified the build system will re-run CMake to re-configure the file and generate the build system again."
So using configure_file should be a safe to trigger the re-run of cmake.
From a user perspective, I would expect other commands to extend CMAKE_MAKEFILE_DEPENDS, too. E.g. execute_process (on demand) but also file(READ) (implicitly like configure_file). Perhaps there are others. Each read file is likely to influence the generation phase. As an alternative it would be nice to have a command to just extend the dependency list (hint for the cmake developers, perhaps one comes along).
I am currently having a bear of a time trying to compile a moderate sized library with a brand new toolchain, Assimp on Xcode6 with the new iOS 8.0 SDK.
Bundled with the project are various scripts and Xcode projects that have configurations for building on iOS, but unfortunately none of them work out of the box.
So far the farthest I have gotten is by using a build script which uses the cmake "Unix Makefiles" method to assemble static libs. Other methods would include using cmake to generate Xcode projects to use to build. I tried that also to no avail, and neither did the Xcodeproject that comes with the project in the repository (which I later learned was marked deprecated in one of the readme files).
Okay, so with this "Unix Makefiles" cmake script I have been able to generate some of the static libs (after manually forcing static lib generation inside the main CMakeLists.txt), but when it went on to build for i386 and x86_64 architectures for iPhoneSimulator it kept pulling in the headers for iOS which caused a torrent of compiler errors.
Luckily I followed a hunch and found assimp/code/CMakeFiles/assimp.dir/flags.make which is one of the cmake-generated files, and lo and behold, the entire cflags was in here, and once I removed the rogue header include path, the make call finally succeeds and I have my iPhoneSimulator static lib!
Okay so the question that I have is basically where do I get started when debugging these frustrating cmake problems. My relationship with cmake has always been a strained one because none of cmake's complexity and design principles ever made sense to me, and very infrequent are the times when cmake builds work for me out of the box... it is always something that almost works but then I have to spend hours debugging with make VERBOSE=1 and then haphazardly poking at generated files, which are of course all marked with warnings to not edit them as they are generated files.
I realize that some of the variables here are perhaps relevant to my troubles. But it isn't clear to me how I can debug these variables. Where do I go to print out these variables so that I can find which variable contains erroneous values? For example, in this most recent situation I had a -I flag that was cropping up in the wrong place. Luckily I was able to find a file that contained it using various large-hammer methods that involve grep but I am not close to actually fixing the build configuration to make the process any less painful in the future.
For complex CMakeLists.txt files I have found the variable_watch command can sometimes be useful (documentation here). It doesn't make it easy, but gives you another level of information.
I am using qtcreator 3.2.1 with CMake. I often add or remove files to my projects (i.e. to the CMakeLists.txt files) and the standard way to have these files shown in the Projects view is to run CMake from the Projects tab: no problem so far.
My problem comes in when I actually run CMake: I always have to re-enter the CMake commad line, it seems qtcreator does not store it and it is a pain in my workflow.
Anyone having the same problem as I do? Or even better, a fix?
Thanks,
Antoine.
CMake is actually running correctly within qtcreator. Forget about this question: things are straightforward in qtcreator and work as well as in plain CMake:
- at the first time you run CMake you need to enter the command line
- it is then stored into the CMakeCache
- so the next time you run CMake you can simply click on "Run CMake" with a blank command line
Easy!
PS: thanks to pmr for showing me the right direction ;)
Is there a possibility to debug CMakeLists.txt files (at least listing of variables) except for the message statement?
There is no interactive debugger for CMake, however there are also the flags -Wdev, --debug-output and --trace which might help. Also remember to check the log files CMakeFiles\CMakeOutput.log and CMakeFiles\CMakeError.log which mainly collect outputs of processes called by CMake (for example while checking for presence of a type or header).
Since version 3.7, CMake now officially supports a "server mode" so integration in IDEs is likely to improve in the near future. Initial support exists both in Qt Creator and Visual Studio 2017 RC
You can try using the new CMake Script Debugger provided by the VisualGDB tool. It uses an open-source fork of CMake that supports stepping through CMakeLists.txt files, setting code/data breakpoints, evaluating/changing variables, etc.
There's a detailed step-by-step tutorial on the new debugger here
I like to use variable_watch to "debug" my CMakeLists.txt files. Just set in top of my script:
variable_watch(SOME_MY_VAR)
There are steveire's CMake Daemon Tools. I haven't used them myself, but they claim to offer possibilities for introspection that seem to be pretty close to a debugger.
Edit: They are now called CMake-server and are part of CMake 3.7.
Also, read about the env var VERBOSE: https://cmake.org/cmake/help/latest/envvar/VERBOSE.html
I used it this way:
export VERBOSE=defined
make
and got some more verbosity.
In other cases, edit CMakeLists.txt file to include the following line:
set(CMAKE_VERBOSE_MAKEFILE ON)
(Some post on this is https://bytefreaks.net/programming-2/make-building-with-cmake-verbose ).
Also, there are useful cmake options controlling debug output, see the manpage: https://cmake.org/cmake/help/latest/manual/cmake.1.html