importing a new project: running cmake in a pre-existing build directory

René J.V. Bertin rjvbertin at gmail.com
Sat Jan 9 10:12:51 UTC 2016


Hello,

I have a few questions about opening new projects that I'd like to ask before hitting BKO ... posting on the "users" instead of the "devel" ML for potential "me too" reactions.

I understand that KDevelop5 now needs to run cmake in order to import a project. So be it ... if at least it does that only the 1st time a project is loaded (but that's not the case?!). I seem to remember from an earlier exchange about this topic that cmake will reuse the options it was run with before, provided you don't give any conflicting options.

However, here's what I just saw after I opened an existing project with its existing build directory for the first time:

%> /opt/local/var/macports/build/_opt_local_site-ports_kde_ECM/kde-extra-cmake-modules-devel/work/build> /usr/bin/cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_BUILD_TYPE=Debug /opt/local/var/macports/build/_opt_local_site-ports_kde_ECM/kde-extra-cmake-modules-devel/work/ECM-5.1x.git

A couple of things that strike me as evident bugs here:

- The session has /opt/local/bin/cmake configured as *the* cmake command (and that file exists)
- I did not configure any options for CMake, but yet there is the specification of a CMAKE_BUILD_TYPE that SHOULD NOT BE THERE . To make things worse, the CMake configuration dialog continues to deactivate the cmake options widgets when you select a pre-existing build directory.
- From worse to worser: re-running cmake with the *correct*  settings is useless as KDevelop will rerun another pass just as soon. At least that's what happens with the newly imported project (a git/clone of extra-cmake-modules); a project that had already been opened in the session doesn't show this behaviour.

This is a serious problem that basically excludes KDevelop5 from the main use I'd have for it, one where I need to run cmake under tightly controlled settings. As I said, I can live with a one-time cmake run which I can compensate for immediately. But that's only as long as I can be sure that this won't happen at unforeseen moments afterwards.

It looks like the absence of a compile_commands.json (output from CMAKE_EXPORT_COMPILE_COMMANDS) may be related to the auto-redo-cmake issue I'm seeing. It also appears that I can create an empty compile_commands.json file without ill effect on KDevelop, and that that file will stop it from rerunning CMake all the time.
If that's correct (i.e. KDevelop can do without the file if CMake doesn't have reason to create it), why not use another placeholder file to record the fact that cmake has been run at least once to import the project? Or, just do a `touch compile_commands.json` after that initial cmake invocation, which will create the file if it doesn't exist and won't change anything otherwise?

R.


More information about the KDevelop mailing list