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

[Tobias Hunger]

Hi Rene,

I probably do not fully understand what you are doing, so please be
patient with me:-)

On Thu, Jun 8, 2017 at 3:07 PM, René J.V. Bertin <rjvbertin at gmail.com> wrote:

> 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.

Thank you for taking the time to provide your feedback instead of just
running off to greener pastures! I very much appreciate the feedback
on our cmake support: Without it CMake support in Creator would not be
where it is today.

> 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.

Can you register your wrapper script with creator? That should work,
provided it it (mostly) transparent and forwards the relevant
arguments to the real cmake.

> What's really missing from Creator is support for a separate configuration step with exact control of the arguments to be used.

What do you mean here? You want the call to cmake to configure the
project to be more explicit? Make/ninja are calling out to cmake all
the time. Why would creator not do the same? It needs the same level
of information.

> 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.

Sure it does.

It starts cmake and asks it for information on the project you opened
directly. At least it does in server-mode. With the older
tealeafreader mode it just runs cmake once to make sure the
configuration is still up to date.

> 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.

Is one of these projects open-source? Can I open such projects on
Linux for testing? I'd like to give this a whirl:-)

> The basic cmake (v3.8.2) call is

So you almost certainly have server-mode in your cmake:-)

> %> 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

I do not see why that would not work from creator.

The CodeBlocks part is optional for you (your cmake has
server-mode;-). So -G "Unix Makefiles" is ok. You can define the
generator in the Kit.

CMAKE_BUILD_TYPE=MacPorts can be configured as well. If you want to
use this setting a lot, then you can set this up in the Kit as well.
It has a section for CMake Configuration settings. That configuration
will then be used whenever that kit is used. You can also set this via
the project configuration if you do not want to see this applied so
widely. You will need to manually add it there though.

CMAKE_EXPORT_COMPILE_COMMANDS is not used by creator. You can still
add it, with the same options as for CMAKE_BUILD_TYPE.

> When I import the resulting build dir in Creator I don't see the source in the IDE, but install tree.

What does that mean exactly? You do not see the files in the source
directory but a list of files as they are installed?

> 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...)

I have considered using compile_commands.json file, but that would
just be another hack that will fail for non-trivial projects. You get
the exact compiler call for all source files from that file, but there
is no context information in it, so you can not say which call belongs
to which target. That is problematic when you build the same file
several times -- something that happens a lot in the wild, e.g. in
tests.

Best Regards,
Tobias