Hi Tobias,

On 31.03.2016, at 21:27, Hunger Tobias <[email protected]> wrote:
> On Thu, Mar 31, 2016 at 8:23 PM, Nikolaus Demmel 
> <[email protected]> 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


_______________________________________________
Qt-creator mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/qt-creator

Reply via email to