[Qt-creator] importing "foreign" cmake projects remains problematic

[René J.V. Bertin]

Hi,

I've had another look at the current state of things in Qt Creator (v 4.3.82 aka 4.4.0 beta1), esp. CMake support.

There are things that seem to have improved, enough that I am getting interested in trying out the IDE, but CMake support remains problematic enough that I can't for most of my projects.

As a reminder, I maintain packaging scripts for use with a build/distribution system which requires projects to be configured through that system (MacPorts to be exhaustive; building with direct make or ninja calls is a lot more trivial once the configuration has been taken care of).

I have a wrapper script that can be called instead of cmake and that ensures that the proper command is executed which will in turn execute cmake with the appropriate arguments. What's really missing from Creator is support for a separate configuration step with exact control of the arguments to be used.

I also notice that Creator still calls cmake (without any control over additional arguments) even if the "automatic" option is disabled in the CMake settings panel.

But that's maybe not the only glitch. I tried to import one of those MacPorts projects, configured as usual but with the "CodeBlocks - Unix Makefiles' generator under the assumption that Creator would be able to infer the project structure from that. The basic cmake (v3.8.2) call is

%> cd /path/to/work/build ; cmake -G "CodeBlocks - Unix Makefiles" -DCMAKE_BUILD_TYPE=MacPorts -DCMAKE_EXPORT_COMPILE_COMMANDS=ON <other options> /path/to/work/source

When I import the resulting build dir in Creator I don't see the source in the IDE, but install tree. The same thing happens with CodeBlocks, btw, so this may be more a problem with Cmake's CodeBlocks generator than with Creator. I do note however that KDevelop imports the same configured project perfectly, using the compile_commands.json file that is created because of CMAKE_EXPORT_COMPILE_COMMANDS . (Not really surprising given how the intended target user of that file - the Eclipse IDE - is in a completely different league as CodeBlocks...)

Cheers,
René