Distinguish between required and optional dependencies

[leorich]

I feel like i must be missing something, but I can't find a way to distinguish between optional and required dependencies.

If I list a dependency in the "dependencies" section of colcon.pkg file, and that dependency is not found, I get an error in this form:

ERROR:colcon.colcon_cmake.task.cmake.build:Failed to find the following files:
- foo/package.sh
Check that the following packages have been built:
- foo

However, for the package i am trying to build, foo is an optional dependency. I was expecting to find something in colcon that lets me specify wether a dependency is required or optional.

For context - I am experiencing this issue with cmake packages

[cottsay]

There isn't any mechanism to discriminate between required an optional dependencies in colcon. I'm sure there are use cases that could take advantage of such support, but thus far it hasn't really been necessary.

When colcon starts up and constructs the dependency graph for the workspace, it pretty much ignores any dependencies which aren't found. So if package bar depends on foo but there is no package named foo in the workspace, colcon will attempt to build bar without making a fuss. However, if foo IS a package, then colcon will get raise an error prior to attempting the build letting you know that the dependency is (probably) not satisfied and that you should (probably) build foo before attempting to build bar. If you want to try anyway, you can ignore the offending package (which is distinct from skipping it) by using --packages-ignore foo.

The error you're seeing is something different. My guess is that at some point foo was built successfully in your (merged) workspace and that part of the package was deleted from the install space - notably the share subtree, but not the entries in the colcon index which lead colcon to believe that foo should have been installed. If you'd like to have the ability to delete packages from your install space, you shouldn't use a merged workspace. However, you should still be able to work around this error with --packages-ignore foo.