Skip to content
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

Resolving ament packages at build time #472

Closed
rhaschke opened this issue Jul 4, 2023 · 4 comments
Closed

Resolving ament packages at build time #472

rhaschke opened this issue Jul 4, 2023 · 4 comments
Labels

Comments

@rhaschke
Copy link
Contributor

rhaschke commented Jul 4, 2023

Debugging ros/xacro#325, I noticed a chicken-egg-problem in ament_cmake:
The cmake function xacro_add_files runs xacro at build time. To resolve $(find current_package) within xacro files, xacro relies on a properly configured ament package index. However, this index is only created after building, during installation.

By manually prepending AMENT_PREFIX_PATH with the current project's ament_cmake_index in the build folder and symlinking the source folder into the corresponding share folder (to resolve source files for xacro), I was able to work around this shortcoming (ros/xacro#326).

However, a fix in ament_cmake would be definitely better. I suggest creating the corresponding package resource in the build folder and the symlink to the source folder directly when calling find_package(ament_cmake).

@furushchev
Copy link

furushchev commented Jul 5, 2023

@rhaschke Thank you for raising the issue! I'm also on the same page.

The limitation that any script running at build time cannot refer to the resources of itself is quite significant.
At least, it should be documented for developers migrating software from ROS1.

By manually prepending AMENT_PREFIX_PATH with the current project's ament_cmake_index in the build folder and symlinking the source folder into the corresponding share folder (to resolve source files for xacro), I was able to work around this shortcoming

This is a nice workaround. The downside is if any custom destination is set ininstall function in CMakeLists.txt, it will not work.
Another idea is to copy resources which are declared in install function to build directory, and then run any scripts. But it will take more time/storage to build if we have many files to copy.
(I realized the build-space and install-space paths have to be the same, so the case should not happen)

Any further discussion is really welcome!

@clalancette
Copy link
Contributor

One suggestion we have here is to change xacro_add_files so it takes a list of the resources it depends on. In turn, that cmake function would then populate those files in both the build directory (so it is available while compiling) as well as the install directory (so it is available at runtime). Then it would also add in a fake ament resource hierarchy in the build directory so it could be found at compile time.

@rhaschke
Copy link
Contributor Author

One suggestion we have here is to change xacro_add_files so it takes a list of the resources it depends on.

xacro_add_files already gets the name(s) of the main .xacro file(s) to be processed as resources. The dependent files that are included from these main files, should not be explicitly listed there. This would be a degradation of usability.

In turn, that cmake function would then populate those files in both the build directory (so it is available while compiling) as well as the install directory (so it is available at runtime). Then it would also add in a fake ament resource hierarchy in the build directory so it could be found at compile time.

That's what my workaround is actually doing. My suggestion was to implement that behavior here in the upstream package. Of course, if you don't see the utility of such behavior in general, I can stick with my workaround.

@rhaschke
Copy link
Contributor Author

Closing due to inactivity. Using the implemented workaround in xacro instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants