Add additive cmake-args option

[jpsamper2009]

Request

This is a feature request to add an option to append cmake arguments to the cmake-args defined in the defaults.yaml: e.g.

$ colcon build --cmake-add-args -DCMAKE_EXPORT_COMPILE_COMMANDS

• Naturally, if no cmake-args are set in the defaults, cmake-add-args will behave exactly like cmake-args, so there may be a better way to address the use-case

Use-case details

• We use a colcon defaults.yml file to standardize the colcon build options for developers; for the scope of this ticket, we are setting a few CMake variables with cmake-args
• Occasionally a developer will need to adjust the cmake configuration from the command line: e.g.
  • Build type
  • CMake verbosity
  • CMAKE_EXPORT_COMPILE_COMMANDS
• The obvious way to do this is by using --cmake-args; however, this overwrites the defaults.yaml (which is intended behavior https://github.com/colcon/colcon-cmake/issues/29); unless the developer copies all the options out of the defaults.yaml
  • So a command like colcon build --cmake-args -DCMAKE_BUILD_TYPE=Releases becomes colcon build --cmake-args -DCMAKE_FLAG_1... -DCMAKE_FLAG2... -DCMAKE_FLAG3... -DCMAKE_BUILD_TYPE=Releases
• This feature would allow developers to use the shorter command

Known alternatives

1. Add the options in the defaults.yaml
   • The main disadvantage is that it requires editing a file to toggle between two options, so, e.g., to toggle between building verbose and not verbose, one has to open, edit, save, build, open, edit, save, build
2. Use a mixin
   • This is already possible for build types, and we could create one for verbosity, etc.; however, does it really make sense to create a mixin for every CMake option that one may want to toggle?

[dirk-thomas]

A default argument is just that - a default value. An explicitly provided argument replaces a default value. That is conceptionally the same in e.g. argparse. So using defaults.yaml for your intended purpose is not going to work (and it is not supposed to work for your use case, you already referenced #29 mentioning that).

Add the options in the defaults.yaml

• The main disadvantage is that it requires editing a file to toggle between two options, so, e.g., to toggle between building verbose and not verbose, one has to open, edit, save, build, open, edit, save, build

This use case is covered exactly by a mixin. Mixins are different from default values since when they are being used they can be combined with explicitly passed arguments (in the case of nargs=* like --cmake-arg).

If your intention is to mix and match various different options independently based on your dynamic needs (e.g. toggle between building verbose and not verbose) a mixin sounds like the way to go for me. At the end of the day a mixin just simplifies you writing the full option (or even multiple) and instead use a mixin name as a shortcut. It will also allow you to share these mixins with your team using a custom mixin repository (or contribute them to the standard repository).

Use a mixin

• This is already possible for build types, and we could create one for verbosity, etc.; however, does it really make sense to create a mixin for every CMake option that one may want to toggle?

If you want to toggle them independently how else would you like to choose what set of options should be used in the very moment? As mentioned above a mixin name is simply a "shortcut name". You can create mixins for each individual option you want to toggle or group them in order to toggle multiple at the same time - it is basically your choice.

---

An orthogonal but related concept would profiles: #168. Each profile would again be a set of options grouped under a convenient name - and likely with a specific profile being used if none is specified.

[jpsamper2009]

@dirk-thomas I've realized that I was thinking about it backwards: I can use a mixin to set the default value and use cmake-args to add cmake arguments (on the command line); the mixin would be part of the defaults.yaml, and would only get overwritten if someone uses one of the alternate mixins. With that being said, I'll close this ticket.

[dirk-thomas]

I can use a mixin to set the default value and use cmake-args to add cmake arguments (on the command line); the mixin would be part of the defaults.yaml, and would only get overwritten if someone uses one of the alternate mixins.

Depending on what your default mixin contains you might run into the same problem if the user passes an orthogonal mixin. The default mixin would not be used anymore even though that might ve intended since its content is unrelated to the one the user passed.