colcon / colcon-core

Command line tool to build sets of software packages
http://colcon.readthedocs.io
Apache License 2.0
99 stars 44 forks source link

No executable found for scripts when using --symlink-install and install(PROGRAMS) #638

Open yschulz opened 3 months ago

yschulz commented 3 months ago

Running ubuntu 22.04, ros2 humble from binaries

Problem description

I have noticed issues when using --symlink-install with colcon build. I have scripts in my project that I would like to invoke after installation. Therefore, I added

install(
  PROGRAMS ${my_script_files}
  DESTINATION lib/${PROJECT_NAME}
)

to my cmake lists. However, when using --symlink-install I cannot index or run them.

Desired behavior

Being able to index and run my scripts whether or not using --symlink-install

Actual behavior

I cannot index or run those scripts because they are only linked and not made executable.

I assume with --symlink-install all instances will be linked nondiscriminatory. However, I feel like using --symlink-install should not break the installation process if I directly tell cmake that my files are supposed to be executables.

fdila commented 1 month ago

I'm having the same issue, ubuntu 22.04 and ros2 humble.

cottsay commented 1 month ago

I'll start by letting you know that colcon is not responsible for performing this symlinking, and that ament_cmake is where this happens. Unfortunately, I can't transfer an issue cross-organization, so we'll probably have to open a new ticket there.

I feel like using --symlink-install should not break the installation process...

100% behind you. Something needs to change here.

The biggest issue I can see is that symbolic links on Linux with ext4 do not have their own set of permissions. We can't create a symlink to a file and then make the symlink executable. The symlink has the same permissions as the file it links to.

A couple of options to move forward:

  1. Detect this scenario and fall back to the non-symlink behavior while possibly displaying a warning
  2. Refuse to do anything and demand that the developer make the original script executable so that we can proceed with the symlink

As it happens, Windows symlinks have separate permissions and access is restricted based on both sets of permissions. None of that seems to matter, however, because on Windows scripts need read permission to be executed, not execute (which is confusing).