Detect nested workspaces and use the outermost workspace by default #705
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
At the moment catkin_tools refuses to create nested workspaces with the
catkin initverb and always uses the innermost workspace where the.catkin_toolsmarker directory is found, starting from the current working directory or the hint passed via the--workspaceor-wargument.This pull request is more meant as a question rather than a request to merge. Would a patch like that, or parts of it, be accepted for upstream, eventually with some polishing? Or does anyone has better ideas/best practices on how to solve the following use case?
Use case:
We sometimes commit the
.catkin_tools/profiles/*/config.yamlfiles with predefined profiles to a Git repository, which is very convenient to share build profiles and commonly used cmake flags within the team. All the other files in.catkin_tools/are ignored by.gitignoreentries. Some of those repositories can be included in others as Git submodules, that then symlink to all or a subset of the catkin packages from their respective source-space and typically have their own committed.catkin_toolsdirectory.Without this patch it happens that the
catkin buildand other verbs pick up the innermost workspace depending on the curent working directory, which then leads to unexpected results when sourcing the devel- or install-space of the outermost workspace and the update has not been applied.I am aware that nesting workspaces like that may not be the smartest idea, and the more standard approach is to strictly separate source repositories and those "workspace" repositories that combine multiple source repositories, documentation, scripts, Dockerfiles etc. for a specific project. On the other hand you then always need an extra repository, for example to run CI for each source repository without replicating the build configuration.
Proposed solution:
Instead of the innermost, always find the outermost workspace in
find_enclosing_workspace()and do not refuse to create nested inner workspaces if asked explicitly with--workspace/-w. The breaking change is that--workspace/-wmust always point to exactly the workspace root, not to any directory within, because otherwise a call likewould be ambiguous again if
/path/to/workspacealready has a.catkin_toolsmarker directory. Eventually it would make sense to print a warning in case a workspace is initialized within another workspace, that then would not be used by default bycatkin.