For example, when I change the compiler, the whole cache is deleted and needs to be reconfigured. I understand that things like the compiler flags would need to be reset but why the whole cache?
Turning my comment into an answer
The Message itself
The CMake message
"You have changed variables that require your cache to be deleted. Configure will be re-run and you may have to reset some variables. The following variables have changed: ..."
translates to something like
"CMake tries to behave and is not telling you that for a change like that you have to delete your binary output directory and start from scratch again."
This feature came a long time ago with "ENH: fix for bug 6102, allow users to change the compiler" commit and was improved with "Delete entire CMakeFiles directory when deleting CMakeCache.txt" commit:
Fix this simply by teaching cmCacheManager::DeleteCache to remove the
entire CMakeFiles directory recursively whenever it removes an existing
CMakeCache.txt. This fully resets the build tree to configure with a
fresh compiler.
Why does it have to delete everything?
If you change the compiler or upgrade to a newer version of CMake, your generated build environment could not just simply be adapted.
All cached configurations - as being an evaluation or search results based on the compiler and platform information - have to be deleted and re-run. CMake could simply not know which cached variable is still valid in the new environment.
Related
New to CMake. When adding libraries I see a lot of instructions saying do this:
cmake -D OPENSSL_ROOT_DIR=/usr/local/opt/openssl
Why is that preferred over putting it in the actual CMakeLists.txt? e.g.
set(OPENSSL_ROOT_DIR "/usr/local/opt/openssl")
You do not commit the first one to the repository while you either commit the second one or have to be careful to not commit it with other stuff.
The second method is usually used to allow users of some project to modify some aspect of that project. So whatever pertains to the project itself (not customizable) goes straight to the CMake files everything else might be provided from the command line.
Note, also, that the CMake presets add an ability to customize the build outside the CMake files so the method of providing variables directly via a console call is something I'd expect going away and getting replaced with presets. But the way they work is still the same: variables defined in the preset get to CMake cache with generated console call (with an IDE it might be different).
My incremental CI builds frequently get:
##[error]CMake Error: Target xxx has dependency information when it shouldn't.
##[error]Your cache is probably stale. Please remove the entry xxx_LIB_DEPENDS from the cache.
Is it safe to delete the cache file before each build?
Will most build binaries be still up to date, or will this trigger a full rebuild?
Someone answered here, but it was removed. So i answer it myself with a link to this question in the CMake forums:
if you delete CMakeCache.txt before each build you must make sure to
configure and generate cmake. Without it is not “safe” because the
cached variables are missing in the next build.
Deleting CMakeCache.txt should not affect any binaries, a full rebuild
is not triggered. Otherwise you might have a local variable passed on
before being cached which then leads to inconsistent runs.
The regeneration of the project can trigger rebuilds if the
configuration is different to the previous one.
Thanks #hex
I'm doing some refactoring (more than what CLion can do automatically) and making lots of changes. When I change a header file, it prompts a significant fraction of my project to rebuild, but I know the error messages will always come from the same spot (which unfortunately starts with "w").
Is there any way to control where CLion will start building so I don't have to wait 30s+ to get the next error message?
I've been typing make src/workflow.o in a console (I tried using the CLion console, but that doesn't make links from errors), but I'd rather have the direct links to the error location.
You can add another cmake target to build only the stuff you need.
See e.g. here:
https://www.jetbrains.com/help/clion/2016.1/creating-and-editing-run-debug-configurations.html?origin=old_help
I am currently trying to swap static libraries in one of my projects which requires swapping find_package() commands for explicit links to static libraries. One of the problems I encountered is that even after deleting find_package() commands reloading the CMake Project the old variables are still present.
Is there a way to explicitly flush the CMake cache other than manually deleting all files from the temporary folder Clion creates for building the project?
Starting with CLion 1.5 144.3143 (2016-01-20), you can clear the cmake cache without loosing the CLion indexes and without restarting (meaning: very fast, also on huge projects):
Tool | CMake | "Reset cache and reload project".
If that for some reasons is not enough, or if you have an older CLion, you can do the more radical:
File | "Invalidate Caches / Restart"
and click on "Invalidate and restart".
EDITS
2016-01-20: add the faster method available with newer CLion.
There is some magic with this cache.
I got bad value for one variable once: by some reason cmake found some wrecked freetype includes inside mono.framework (another reason to dislike mono...) and tried to use them to compile my project. Obviously compilation failed.
I tried to remove CMakeCache.txt and rebuild project but incorrect path come back. Even after I removed mono.framework dir!
The solution was to remove incorrect line from the cache and restart the build. After that cmake got the correct path and build succeded.
UPD:
After I "reload cmake project" incorrect value came back. Deleting everything in $HOME/Library/Caches/clion11/cmake/generated/ dir (for OS X) seems to finally solve the issue.
I am getting the above error message randomly (so far as I can tell) on iPhone projects. Occasionally it will go away upon either:
Clean
Restart XCode
Reboot
Reinstall XCode
But sometimes it won't. When it won't the only solution I have found is to take all the source material, import it into a new project, and then redo all the connections in IB. Then I'm good until it strikes again.
Anybody have any suggestions?
[update 20091030]
I have tried building both debug and release versions, both full and lite versions. I've also tried switching the debug symbols from DWARF with external dSYM file to DWARF and to stabs. Clean builds in all formats make no differences.
Permission repairs change nothing.
Setting up a new user has no effect. Same error on the builds.
Thanks for the suggestions!
[Update 20091031]
Here's an easier and (apparently) reliable workaround. It hinges upon the discovery that the problem is linked to a target not a project
In the same project file, create a new target
Option-Drag (copy) all the files from the BAD target 'Copy Bundle Resources' folder to the NEW target 'Copy Bundle Resources' folder
Repeat (2) with 'Compile Sources' and 'Link Binary With Libraries'
Duplicate the Info.plist file for the BAD target and name it correctly for the NEW target.
Build the NEW target!
[Update 20100222]
Apparently an IDE bug, now apparently fixed, although Apple does not allow direct access to the original bug of a duplicate. I can no longer reproduce this behaviour, so hopefully it is dead, dead, dead.
Troubleshooting steps:
(1) dsymutil deals with debug information so you should probably start with the debug build. Once the problem starts can you run the release build?
(2) Create a new users and work from there to see if the problem follows. If not the problem is most likely a corrupted file in your user's directory.
(3) In my experience most linker problems are caused a permission problem somewhere. (We have to pay for security.) I would repair permissions and see if the problem goes away.
(4) In the extreme you can uninstall the dev tools from the command line:
sudo /Developer/Library/uninstall-devtools --mode=all
However, this won't help if the problem is in your user's directory. In that case, you might need to work under a new user or spend a lot of time tracking down every dev related file in the user directory.