-
Notifications
You must be signed in to change notification settings - Fork 279
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
allow catkin_make to rebuild individual packages (after initial invocation) #348
Comments
Same for catkin_make_isolated (hope no new ticket is needed). |
Reopen for catkin_make_isolated. |
As a minor addition: It would be nice if |
Or, more generally, build all packages found in the current directory and its subdirectories (e.g. making a whole "stack"). |
The problem with that is the CLI syntax that allows also adding target names to the command. So probably a different --option would be required for that. |
Maybe |
You mean catkin_make --pkg |
Yes, but I only intended it for the current workspace. Mainly aimed at the common use case that you are in a package directory and want to build just that (or maybe including your suggestion the current directory + subdirectories). Building other workspaces might be dangerous, but I'm not sure about that. Peeking into @dirk-thomas commit 1bde827, I think there is already a check to verify that whatever is passed is actually a package, so it should be safe. |
Might be easier to define a new alias or custom shell script wrapper around catkin_make for that purpose. |
Also look at my comment to #352, the general problem when doing this for multiple packages is that we have to build them in the right order. The same goes when scanning subdirectories. So it's a can of worms if we allow subdiretories as well. If we go for |
I think these are two separate issues. I suggested Interpreting |
Allowing multiple package names is possible. But be aware of the restrictions! The following command:
will build the two packages "foo" and "bar". "bar" can by definition not be a target. The combination of --pkg and target names does not make sense anyway, but if done it must be specified:
Calling --pkg without an argument can be done if invoked in a folder with a package.xml file using that package name. We should not allow paths as arguments to --pkg for the simple reason that it can not be done consistenty. If I can specify "." I should also be specify "subfolder" and that is not possible sinde "subfolder" could at the same time be a package name. I am fine implementing this if we are all aware of the implications. But please come up with feedback now. We need this done without changing it over and over again. |
These restrictions / behaviors sound good to me! I also like being able to call |
I like it exactly as you proposed, i.e. everything after The "special" syntax of Paths shouldn't go in this issue as there might be confusions of what the command should do. This could go into |
@dirk-thomas: Have you considered the implications for build ordering? I.e. will package be build in the order specified by the user or ina an order that follows the dependency tree? |
It must utilize topological order but that should be easy to achieve. |
It can do that by invoking the Makefile under build/path/to/pkg. Since a positional argument would collide with the targets we need a named argument for that i.e.
--pkg
.The text was updated successfully, but these errors were encountered: