The time it takes to complete a reload CMake files seems to continuously going up. There's the time it takes to actually run CMake, but that is a small part of the total time it takes since CLion also spends a lot of time on indices.
This time seems to be steadily increasing for my project. The index building used to take about 30 seconds (version before 2016.1), then during 2016.1 EAP it crept up to 85 seconds, and now with a recent EAP I think it is starting to go above 100 seconds.
I noticed that I could significantly reduce the reload time by mark all my gtest applications as excluded (over 50 gtest projects). This drops the reload cmake file time for my entire application to about 15 seconds. That is however not ideal since my gtest applications then are ignored. This in turn leads to a 200+ contexts and I'm suspecting that each context comes at a price. There are four contexts per binary, right?
Reloading the cmake files taking a long time wouldn't be a big deal except for the fact that I need to reload the cmake file every time I add a cpp-file. Waiting that long every time you add a class is a problem.
I wouldn't be surprised if we are doing something in the cmake files which is sending CLion for a goose chase for no good reason. Are there best practices for how to construct a CLion friendly CMake environment? Things to avoid? Ways to optimize?
For instance, we have something called CoreLibs. This is a set of libraries that are commonly used. We tend to include them in each gtest app, however, even if they are used often, for each individual app we are probably using less than half of those libraries. I'd be willing to go through and optimize our build environment so that each test app only has the libraries it needs and nothing else. Problem is, that would take days and I don't know if it'll have any effect at all.
From a feature point of view I'd love it if the re-loading the cmake files could be made faster (and note, the running of cmake itself is only about 5 seconds). I'm not sure how you could improve things, but I understand that you are creating four contexts per application by default. I tend to change from debug to release or vice versa far less often than I add classes so that might be a possible avenue. I'd much rather have changing from release to debug take a really long time than to add a class.