colcon.pkg is read but not used about colcon-core HOT 3 CLOSED

The feature for colcon.pkg files is provided by the colcon-metadata package.

The *.meta / colcon.pkg can contain metadata about the package, like its name, type, dependencies, hooks etc. Additionally they check for any configuration option which matches any of the command line options. For that they don't take the verb into consideration - so cmake-args would be applied to every verb which does have that as a valid command line option.

Please try to remove the build entry and move the cmake-args entry to be a sibling of name. An example (slightly different since the first two levels identify a package by name): https://github.com/colcon/colcon-metadata-repository/blob/6b81483901cbcc242029312725a21b650f6273a3/fastrtps.meta#L4

from colcon-core.

Thanks for the explanation, now it works!

Just for info: I was following the example given for defaults.yaml, where the options are given below the verb. If you want, I can submit a patch for the docs to explain the difference.

btw, I knew that parsing the meta-files is the responsibility of colcon-metadata, but it looked as if that went right (it found it, and colcon info listed it). But then it was not used by the build step- so it wasn't clear where the issue is. In general, colcon has so many sub-packages that asking people to put the issue in the right place is going to give you more grief than it's worth ;-)

from colcon-core.

I was following the example given for defaults.yaml, where the options are given below the verb. If you want, I can submit a patch for the docs to explain the difference.

Adding a note for the colcon.pkg file would certainly be great. If you could make a PR for it that would be highly appreciated.

On the other hand resembling the same structure as in the defaults.yaml file would probably be better and allow for verb specific different arguments. I created colcon/colcon-metadata#9 to track this feature / change.

In general, colcon has so many sub-packages that asking people to put the issue in the right place is going to give you more grief than it's worth

The link to the colcon-metadata repo was mostly for context. I don't worry about the location of tickets. GitHub does a good job of cross referencing and worst case tickets can easily be moved with something like https://github-issue-mover.appspot.com/

from colcon-core.