A nice to have, addressing #213.

Nice!

if something get's installed in the install folder even if no script exist, doesn't lgtm

Good point. Yeah, empty directory. Ugh. Will fix.

b6cb63b does the trick, but it requires explicit request. I had to add DESTINATION, I hated the asymmetry.

ros-simulation/gazebo_ros_pkgs#1252 does, but I don't think we can run a joint CI. After a Rolling release, perhaps.

I'll get this one merged after the freeze. It's a nice to have and I don't want to break anything 😅

Full CI:

• Linux (unrelated warning)
• Linux-aarch64 (unrelated warning)
• macOS
• Windows

Alright, this is ready to go in. I do not expect any fallout, but I will keep an eye on it for the next few days. If it gives us trouble, I'll revert it right away.

It feels somewhat awkward that one needs to specify SCRIPTS_DESTINATION lib/${PROJECT_NAME} in order to generate and install console scripts. Obviously, this argument is used for two independent purposes:

1. specifying the destination for those scripts (which is always lib/${PROJECT_NAME} by default)
2. enabling the script generation at all

IMHO, only the first point is justified. The generation should be triggered in any case. To ensure that script files are only installed if really needed, one could easily use cmake's file(GLOB ...) to check for the existence of generated script files.

@hidmic, would you accept a PR to make SCRIPTS_DESTINATION optional, using lib/${PROJECT_NAME} by default?
Do you plan to backport this feature to Foxy as well (I have seen a backport to Galactic only)?

would you accept a PR to make SCRIPTS_DESTINATION optional, using lib/${PROJECT_NAME} by default?

@rhaschke IIRC we force explicit request so as to not populate the install space with empty directories (in case no scripts are declared in the setup.py file). If you have a proposal that works around that defect, it's more than welcome!

Do you plan to backport this feature to Foxy as well (I have seen a backport to Galactic only)?

@rhaschke as a general rule of thumb, we don't backport features. Having said that, it should be a fairly innocuous backport. I'm onboard if @jacobperron is.

I have no objection is folks want to backport this to Foxy.

hi. trying to compile foxy on raspberry pi zero. but sadly my project needs xacro which only has one ros2 branch which uses the new "ament_python_install_package" syntax, but because this is not backported to foxy, i get

ament_python_install_package() called with unused arguments:
  SCRIPTS_DESTINATION;lib/xacro

fatal error and it stops to compile.
so i would really appreciate the backport.
thx in advance

so i would really appreciate the backport.

Foxy is now End-of-Life, so we don't have a way to do backports there. I encourage you to try out Humble, where this bug should already be fixed.

But would this run on raspberry pi zero 1? Because compiling on it takes days, and after days compiling to find out, it don't work, wouldn't be great...

@LaneaLucy, you could simply revert the corresponding xacro commit. No need to rebuilt in this case ;-)

@rhaschke I'm now using the last tag of xacro that don't use the new format. It's compiling now, but this will take at least some hours before it gets to the xacro part

You don't need to rebuilt packages if you just changed xacro.

@rhaschke I'm compiling ROS2 from source and it don't re compile packages without change, but on a raspi zero it still takes some time (15s-2min) for colcon to figure out if it needs to compile. And I'm still very new to ros and that's my first ros2 build from source