build: Support cmake --build

[jbohren]

As mentioned in #266, the cmake executable provides a --build option in version 2.8 and later, which calls the native build tool to build a package (see documentation below). This will enable using other generators (Ninja, Xcode, etc) for CMak-based packages.

Instead of directly calling make, we could use cmake --build. If we did this, the abstraction should be clear in the catkin command line interface. To do that, it might be necessary to change --make-args and --catkin-make-args to something that better reflects their generality.

This could be done in ~~two~~ three stages:

• [ ] 1. For CMake-based build jobs, change all direct invocations of make {} to cmake --build --use-stderr -- {}. This would enable this as an "advanced" feature.
• [ ] 2. Extract generator type from CMake -G option to control other features (e.g. disabling parallel packages).
• [ ] 3. Update command-line interface to reflect the new advanced usage.

This supersedes #215.

cmake --build

       --build <dir>
              Build a CMake-generated project binary tree.

              This abstracts a native build tool's command-line interface with the following options:


                <dir>          = Project binary directory to be built.
                --target <tgt> = Build <tgt> instead of default targets.
                --config <cfg> = For multi-configuration tools, choose <cfg>.
                --clean-first  = Build target 'clean' first, then build.
                                 (To clean only, use --target 'clean'.)
                --use-stderr   = Don't merge stdout/stderr output and pass the
                                 original stdout/stderr handles to the native
                                 tool so it can use the capabilities of the
                                 calling terminal (e.g. colored output).
                --             = Pass remaining options to the native tool.

              Run cmake --build with no options for quick help.

[wjwwood]

A few things to considered (which prevented us from using this in our ament tools when we were setting it up to support visual studio projects and msbuild) is that there's no explicit way check for a target's existence (you might be able to catch the failure when the target doesn't exist, not sure) and there's no good way to control parallelism of the build, e.g. -jN for make or /m for msbuild or something else for Xcode, CodeBlocks, etc...

[jbohren]

A few things to considered (which prevented us from using this in our ament tools when we were setting it up to support visual studio projects and msbuild) is that there's no explicit way check for a target's existence (you might be able to catch the failure when the target doesn't exist, not sure)

Do we do that a lot? (check for existence of targets)

and there's no good way to control parallelism of the build, e.g. -jN for make or /m for msbuild or something else for Xcode, CodeBlocks, etc...

Right, and even the JobServer in #249 only supports GNU Make. But if people want to use other generators, then we can force one package at a time for now. Of course we'd need to parse the -G option out of --cmake-args to do that, but that's also easy to do.

[wjwwood]

I think there is a need for it, e.g. plain cmake projects with no install target, skipping projects without a test target (for the catkin test verb), testing for the roslint target, etc.

We check for this in catkin for example: https://github.com/ros/catkin/blob/3b8a3b9607adff98ed32cfd3b6d6ea4aed647424/python/catkin/builder.py#L444-L454

[jbohren]

I think there is a need for it, e.g. plain cmake projects with no install target, skipping projects without a test target (for the catkin test verb), testing for the roslint target, etc.

We check for this in catkin for example: https://github.com/ros/catkin/blob/3b8a3b9607adff98ed32cfd3b6d6ea4aed647424/python/catkin/builder.py#L444-L454

Ah I see. Well that can still be done in the same way by passing those args to cmake --build -- based on which generator is being used.

[tlobig]

Seems like this issue was kinda forgotten. been using the _tools for a while and never knew that _make supported ninja already. Is there going to be any progress on this?

[qhdwight]

Ninja support would be really nice, and I feel like it would be easier to support than say msbuild or xcode

[AlexisTM]

@qhdwight I did work on that (long time ago) but didn't have time to finish it up (very low priority to work on open-source projects due to company policy)

What is left:

• Rebase it
• Test it locally to understand pitfalls (and fix them if any)
• Add unit tests

To test it locally, building the whole of Noetic would be a good start. Also, ensuring the parameter stays over time is important (catkin build --ninja should stay for subsequent calls of catkin build, until (at least?) catkin clean)

https://github.com/catkin/catkin_tools/pull/570

[qhdwight]

Ah thanks you @AlexisTM ! I will take a look and see if it would be possible to update and into a new PR.