[Qt-creator] Generating QtCreator cmake project for given CMakeLists.txt from command line

[René J.V. Bertin]

On Friday April 15 2016 07:59:38 Hunger Tobias wrote:

Hi,

>> Is there a way to prevent QtC from re-running cmake each time it feels like 
>> doing so?
>
>Creator will rerun CMake whenever it feels like doing so, because that is the
>only way to get up-to-date information on the project. CMake is not very
>forthcoming with information:-/

Yes, I know, but wouldn't it be possible to display a "I'd like to rerun cmake" indicator and let the user decide whether that's actually going to happen ... at his/her expense (= project information not being updated)? If you're using an IDE for a development workflow that doesn't take place completely in the IDE you probably prefer to have potentially out-of-date project information rather than having up-to-date information on a misconfigured project ;)

FWIW, KDevelop also dropped its internal cmake parser, but uses the compile_commands.json file generated by cmake when called with -DCMAKE_EXPORT_COMPILE_COMMANDS=ON . As long as that file is present it will not launch cmake itself, but instead (apparently) count on it that cmake is called through make or ninja whenever necessary. In my case that usually means the appropriate environment is in place.
Shouldn't this also work for QtC, supposing that it gets its information not by reading cmake's stdout by parsing some file maintained by cmake?

The alternative would be to provide a way to control exactly how cmake is called, command and arguments (and record that information, contrary to earlier QtC versions that didn't remember the cmake arguments).

The big risk with auto-invocation of cmake on a build directory that is also under external control is that cmake doesn't put up a lock when it's running in a directory.

>Creator will keep the configuration unless at least one of these conditions is
>met:
>
>* The generator (ninja/make/etc.) used to set up a build directory does not
>match up with the one used by the selected Kit.

It'd be nice if it could simply adapt and use the generator from the configured directory, at least as an option.

BTW, the ninja generator creates only a single, toplevel ninja file. Is it still possible to build only a sub directory of a project (i.e. one that has a Cmake file) with that generator?

>* The cmake command that was run to set up a build directory is not the one
>configured for the selected Kit.

That should probably be optional, (much) more so than for the generator.

>Creator no longer clears the cache if the Extra Generator "CodeBlocks" is
>missing.

Since what commit? I'm currently testing a built off last Friday's (Apr. 8th) code base, and at the very least it yells if I don't select a generator with the CodeBlocks generator.

Is it possible that that extra generator causes a lot of overhead for larger projects? I just came across one where even a "make" invocation with nothing to do would take forever to complete, with most of the time spent in cmake itself. Never saw that before.

>I do want to have proper "Import build directory" support for the next version.
>That should then set up a matching kit for a build directory.

That could do the trick too... A kit that will be added to the available kits "forever", or one that will be specific to that project?
What version are we talking about (major, minor, ...)? ;)

Reminds me: does QtC have something like profiles/presets for environment variables (that can be selected per project and are applied before running any configure or make command)? IIRC I've only seen per-project settings that'd have to be recreated for each new project.

Cheers,
René