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

[Nikolaus Demmel]

Sorry for the previous HTML contaminated email! I blame it on my hoster’s webmail client. Now I’m back at my machine. Here it comes again hopefully just plaintext:



Hi Tobias,

On 31.03.2016, at 12:16, Hunger Tobias <Tobias.Hunger at theqtcompany.com> wrote:

> 
>> The catkin_tools workflow is currently supported quite well with qtcreator, given that catkin_tools creates more-or-less standard cmake build directories, one for each ROS package. So go ahead in your new ROS workspace after calling `catkin build`, open the CMakeLists.txt of one of the ROS packages in QtCreator as a project, then select one configuration and point the build directory to <ros-ws>/build/<ros-pkg-name>. Now you can call make from within QtCreator, rerun cmake, have code completion, click on warnings to get to the source location, use the debugger, etc. That is all great.
> 
> You actually should not even need to rerun cmake, provided you set up catkin to use the "-GCodeBlocks - Unix Makefiles" generator we need for Qt Creator. 

Is that enough? That sounds great. I thought that QtCreator might do some more "magic".

This can be run easily for all packages with `catkin build --force-cmake --cmake-args "-GCodeBlocks - Unix Makefiles"`. However I noticed that QtCreator currently reruns cmake in any case whenever you open a project. I think this is fine, and that way the user doesn't even have to remember to call `catkin build` with the `"-GCodeBlocks - Unix Makefiles"` argument manually.

> 
>> The step that is inconvenient, which I was asking about in this thread, is the fact that for each ROS package, you have to manually select the correct build directory and Kit when opening the project. Since there can be many ROS packages in a workspace (>100), it gets cumbersome. That’s why I am looking for a way to generate the project file (CMakeLists.txt.user) from command line without user interaction. I want to be able to specify the build directory(s), and also the configuration(s)/Kit(s). For the latter it would be great if there was a “environment Kit”, which selects compiler/qmake/cmake in the same way that cmake would on the command line (in fact cmake has already been run from the initial `catkin build` call, so QtCreator could just ask cmake what compiler it configured, which would maybe be a sort of “cmake Kit”, where you let cmake run in the current environment determine the compiler).
> 
> My original idea was to use the default build directory setting (Tools>Options>Build & Run>General IIRC) and adapt that for catkin use. Opening the source directory should then automatically pick up the right build directory.

Your idea is to determine if the opened CMakeLists.txt file corresponds to a catkin package, and if yes, use some special logic to determine the correct build directory? This could be the perfect solution, I like it.

> I am not sure this is an option anymore, considering that there are way more directories in $WS/build than there are in $WS/src. I need to check how that mapping from $WS/src/something/other/CMakeLists.txt to $WS/build/somedirectory works to check if that is an option. If"somedirectory" is just the CMake project name, then that should be easily doable already. Considering that such a simplistic mapping would fail in fun ways when you end up with two projects in $WS/src/* sharing the same project name (but in a different filesystem location), I do not think that is what catkin actually does:-)

It might actually be even easier than you think. Bear with me :-).

First, let me explain shortly what is the layout. In the src directory, there might be arbitrarily many catkin packages, at an arbitrary depth in the file tree and are identified by the presence of a `package.xml` manifest file. This file also specifies the name of the catkin package, i.e. the folder name containing the catkin package in the source space is not relevant. One reason why allowing packages ot be nested in the folder subtree of the src directory is important is because often we want to create one git repository with multiple catkin packages in subfolders, and then clone that repo alongside other repositories into the src of our workspace. Now in the build directory, all the top-level folders correspond to the catkin package names, so the folder layout can be much different. Having multiple packages of the same name in a catkin workspace is an error, so we don't have to worry about that. And yes, the cmake project name is also supposed to match the catkin package name.

But maybe you don't have to worry about any of that :-). catkin_tools comes with some built-in commands to query information about the workspace and about packages, meant exactly for tool-support.

For example, to determine if the current directory is inside a catkin workspace you can run

    catkin locate

and it will either print the workspace-root or give you an error.

Then for example to find the build directory of a package foo_pkg, you just run

    catkin locate foo_pkg --build

This even works together with profiles (which are is catkin's support for multiple configurations in the same workspace), so you can query the build directory of a package for each of the profiles (or to keep it simply initially, just for the currently active profile).

This is only a rough sketch, but I think using catkin itself to find the correct folders could be a robust solution. I can certainly help with figuring out the details and edge cases, and also extending `catkin locate` to provide all the informaton we need.

> 
> You would still need to set up the kits yourself then (we need the information there for the code model).

This would actually be a big step already even if you need to manually select the Kit.

> 
> For Qt Creator 4.1 I would like to have a "import existing build" functionality (as we have for qmake-based projects), which will pick a kit based on an existing build directory (and create a new kit if none matches). That requires quite a bit of refactoring of the qmake import functionality so that I can re-use (part of) the code from there. That is why this did not make the cut for Qt Creator 4.0: It was just too late to start a big refactoring when I got round to implement that.

This sounds perfect. I think this could be the last piece of the puzzle to achieve what I had originally intended. :)

How would this work with configurations (Release / Debug / ...). At least with the Makefile backend, a given build directory that you import would correspond to exactly one configuration, namely the one that CMAKE_BUILD_TYPE is set to. Would you then simply only offer this one configuration for that project, or offer to create additional build directories for the other configurations?

> 
>> Of course one could also think about integrating catkin_tools itself better into QtCreator (which is I think what you were talking about), but that is a completely different story and to me catkin_tools is so great from the command line, that I am happy continue using it there in conjunction with editing code in an IDE.
> 
> Oh, OK:-)

The solution above is shaping up nicely IMHO, so maybe we can talk about a deeper integration of catkin_tools sooner than expected. E.g. offering to automatically set the build-step to `catkin build --this` for cmake projects that are detected to be a catkin package inside a workspace should be straight forward once the above is implemented.

Thanks for your ideas! You got me all excited now :-).

Kind regards,
Nikolaus