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

[Nikolaus Demmel]

Hi Tobias,

On 31.03.2016, at 21:27, Hunger Tobias <Tobias.Hunger at theqtcompany.com> wrote:
> On Thu, Mar 31, 2016 at 8:23 PM, Nikolaus Demmel <nikolaus at nikolaus-demmel.de> wrote:
>>> 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".
> 
> We try very hard to not do any magic, especially not with the build systems! Ideally you should be able to open any project using one of the supported build systems without any changes and without any special configuration in Qt Creator.
> 
> That is one of the reasons why I sometimes joke that "Qt Creator is the best IDE for everybody that hates IDEs":-)

Yeah I realize this more and more, and it is great. (Maybe my biggest criticism in that regard would be that QtCreator does nothing from command line, like e.g. the project generation that I was initially talking about).

This is actually to some extend also true for catkin. It tries very hard to make catkin packages behave like a standard cmake package. That’s the reason it already works great with QtCreator or any other IDE that supports plain Cmake. 

> 
>> This can be run easily for all packages with `catkin build --force-cmake --cmake-args "-GCodeBlocks - Unix Makefiles"`.
> 
> In fact I did
> catkin config -DCMAKE_BUILD_TYPE=Release "-GCodeBlocks - Unix Makefiles"

Yup, that works as well to have it permanently configured in your catkin workspace. But since QtCreator runs it as well every time, you can save a few cycles and not run the additional generator when calling cmake through `catkin build`. It shouldn’t hurt though.

> 
>> 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.
> 
> I do not know catkin well enough to comment whether or not that is viable.

I think this is what people have done so far when using QtCreator with catkin. Since I think few people realize that QtCreator simply calls the CodeBlocks generator under the hood, they would not have run it manually. I think we can just leave everything as is for this point.

> 
> Qt Creator will rerun cmake though, since it needs to make sure there is no stale data in the configuration it reads. Who knows what the user did to the project since cmake was last run?

True, but most of the time cmake itself can tell if it needs to rerun or not, i.e. calling `make` will check if it should first re-run cmake, since e.g. one modified the CMakeLists.txt. But in any case, I think QtCreator does fine here, no need to change IMHO.

> 
>>>> 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.
> 
> Even simpler: My idea was to just configure the default build directory for all projects to point to wherever catkin will put its build directories. At this point I am mostly thinking about how you can configure Qt Creator to make things more convenient for you right now (or soon, since I assume you will be using Qt Creator 4.0 for the better cmake experience;-).

Aha, I didn’t get that. That should work (as long as I only open catkin packages, not other cmake packages as well). Thanks for pointing that out again, I didn’t realize this was a setting.

It is somewhat limited though, since a relative path will not work with all packages (as I tried to explain they can be nested arbitrarily deep inside the src folder, i.e. different packages might need different number of “../“ in the relative path. Using an absolute path only works for a single workspace and a single profile. Still I think this could be beneficial to many people, since I assume that working with multiple workspaces and multiple profiles is the exception, not the rule.

Ah, and yes, I am using 4.0 beta ;-).

> 
> <snip long section on catkin implementation>
> 
>> 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.
> 
> Sure, something like that would be best. But that of course requires somebody that knows those tools well to actually implement this:-)

I would feel confident to figure things out on the catkin side of things. I would need some pointers to where additions in QtCreator should be made, though. 

Where would I for example add the conditional code that checks if a cmake project that is about to be opened should be considered a catkin package and then adapt the build directory according to some output of a subprocess call to `catkin locate`? Is there a good example of how to best do subprocess calls in QtCreator (I guess I could look for the calls to `cmake`)?


> 
> <snip>
>>> For Qt Creator 4.1 I would like to have a "import existing build" functionality<snip>
>> 
>> 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?
> 
> I want to generalize the code and reuse as much as possible from the qmake implementation. There we basically use the default build directory as configured by the user for the kits, go up one level and scan all the folders found in that directory. If a directory is found, then all the checkboxes for build configurations are unchecked, the existing directories are shown under the kit they use (with kits being set up for builds that do not match any existing kit) and all these directories are checked.
> 
> So all the configurations should be found (provided you use a somewhat sane directory layout) and clicking on "Configure" should get you rolling with all of them set up.
> 
> That is not perfect for your use-case, but it should seriously reduce the necessary number of user interactions to open one cmake project that is a part of a bigger catkin project.

With the catkin layout the build directories of multiple configuration of a single catkin package will not be siblings in the directory tree. But once you have this working as you describe it for the standard single-package cmake workflow, maybe I can investigate addition conditional logic depending on if a project is detected to be a catkin package or not. I will wait to hear more about your progress on this.


> 
>> 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.
> 
> I will keep your use-case in the back of my mind as I continue to work on Creator's cmake support for 4.1.
> 
>> Thanks for your ideas! You got me all excited now :-).
> 
> I am looking forward to discuss ideas as they evolve, and will await your patches;-)

I hope I can get in there with some guidance on where/how to add stuff — as time allows. I have started by downloading and compiling the source. It’s a start ;-). The first thing I would like to have a look at is the conditional default-build-directory that I describe above. Specific questions requesting guidance are inline in the discussion.

Kind regards,
Nikolaus