allow catkin_make to rebuild individual packages (after initial invocation)

[dirk-thomas]

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.

[tkruse]

Same for catkin_make_isolated (hope no new ticket is needed).

[dirk-thomas]

Reopen for catkin_make_isolated.

[dornhege]

As a minor addition: It would be nice if catkin_make --pkg (no args) would build the package in the current directory.

[tkruse]

Or, more generally, build all packages found in the current directory and its subdirectories (e.g. making a whole "stack").

[tkruse]

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.

[dornhege]

Maybe catkin_make --pkg .? Not sure how consistent that looks.

[tkruse]

You mean catkin_make --pkg <package_or_path> ? That would make us end up being able to catkin_make in other workspaces than the current one (for better or worse).

[dornhege]

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.

[tkruse]

Might be easier to define a new alias or custom shell script wrapper around catkin_make for that purpose.

[tkruse]

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 --pkg<path_or_packagepath, rejecting all paths that do not lead to a package folder inside this workspace, that could achieve --pkg . without too much implications.

[dornhege]

I think these are two separate issues. I suggested --pkg . to avoid confusion of what e.g. --pkg clean means -- build package clean or clean the package in the current dir -- when building the single package in the current directory.

Interpreting --pkg . as a path with subdirectories (or adding --path) would be lead to the same problems you mentioned for building N packages. Maybe that should be resolved first.
Until that catkin_make --pkg $(basename $(pwd)) can be a semi-safe alias.

[dirk-thomas]

Allowing multiple package names is possible. But be aware of the restrictions! The following command:

catkin_make --pkg foo bar

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:

catkin_make targetA targetA --pkg pkgA pkgB

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.

[jbohren]

These restrictions / behaviors sound good to me!

I also like being able to call catkin_make --pkg without any arguments to build whatever package is named in that directory's package.xml.

[dornhege]

I like it exactly as you proposed, i.e. everything after --pkg is a package and if empty it is the current folder (if it has a package.xml).

The "special" syntax of catkin_make targetA targetA --pkg pkgA pkgB looks good to me. I don't see a simpler way.

Paths shouldn't go in this issue as there might be confusions of what the command should do. This could go into --path which would be another different thing to discuss.

[tkruse]

@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?

[dirk-thomas]

It must utilize topological order but that should be easy to achieve.