-
Notifications
You must be signed in to change notification settings - Fork 129
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
Various improvements to ament_python_install_package
#372
base: rolling
Are you sure you want to change the base?
Conversation
The scripts are generated into a build folder and thus *always* need to be copied. No need to distinguish between symlink and other installs. Signed-off-by: Robert Haschke <rhaschke@techfak.uni-bielefeld.de>
Signed-off-by: Robert Haschke <rhaschke@techfak.uni-bielefeld.de>
This avoids the problem of empty install folders as setup.py generates the target folder only if needed. Signed-off-by: Robert Haschke <rhaschke@techfak.uni-bielefeld.de>
Signed-off-by: Robert Haschke <rhaschke@techfak.uni-bielefeld.de>
For example, xacro is install into lib/xacro/xacro and bin/xacro. Signed-off-by: Robert Haschke <rhaschke@techfak.uni-bielefeld.de>
e01c5ab
to
d29798e
Compare
@hidmic, @jacobperron, could you please review? This is blocking ros/xacro#304. Thanks a lot in advance. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to test this locally, but overall LGTM.
) | ||
if(POLICY CMP0087) | ||
# Allow generator expressions in install(CODE...) | ||
cmake_policy(SET CMP0087 NEW) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rhaschke which generator expressions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't use generator expressions, but cmake complains about the unset CMP otherwise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The warning is even reported by CI: https://ci.ros2.org/job/ci_linux/16094/cmake/NORMAL
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I wonder if a generator expression is introduced by build_dir
. Anyways, we need to cap that warning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's what I did. How do you trigger Full CI on this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you trigger Full CI on this PR?
Using our ci_launcher
with a custom ros2.repos
file (see https://ci.ros2.org/job/ci_launcher/9781).
Yes, that's what I did.
What's funny is that I run CI yesterday and there have not been changes to this PR in weeks. Maybe fe6b3a3 was not enough?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm really puzzled. Indeed, the previous builds didn't show the warning - although install(CODE ...)
was already used:
ament_cmake/ament_cmake_python/cmake/ament_python_install_package.cmake
Lines 190 to 191 in 3fc4db9
# compile Python files | |
install(CODE |
However, locally, the suggested change exactly silences the warning for me. I have no clue, why it fails on CI.
My suggestion is to drop it and retry.
This reverts commit fe6b3a3. Signed-off-by: Robert Haschke <rhaschke@techfak.uni-bielefeld.de>
39bab98
to
cc7ad4e
Compare
The ROS2 build farm confirms that the suggested change is required: I still have no clue why your full CI fails anyway. How should we proceed now? |
Hmm, it's just a hunch but I suspect this is an issue with CMake policy scopes. If you look at the console output for, say, full Linux CI, before cc7ad4e, you'll see that most of the packages that generate warnings are packages that build interfaces. That's an important detail because Could it be that by the time your install code runs, CMP0087 has been popped off the stack? |
Looking into the cmake traces of an old and new build of |
# generate/install entry-point console scripts | ||
foreach(_dest ${ARG_SCRIPTS_DESTINATION}) | ||
get_filename_component(ABS_SCRIPTS_DESTINATION "${_dest}" ABSOLUTE BASE_DIR "${CMAKE_INSTALL_PREFIX}") | ||
install(CODE "execute_process(COMMAND ${python_interpreter} setup.py install_scripts --install-dir \"${ABS_SCRIPTS_DESTINATION}\" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
${python_interpreter}
comes from
get_executable_path(python_interpreter Python3::Interpreter BUILD) |
The BUILD
argument will result in the path being a generator expression:
set(output_var "$<TARGET_PROPERTY:${target_or_path},LOCATION>") |
A workaround to make the install(CODE
warnings go away is to call get_executable_path
again with the CONFIGURE
arugment.
get_executable_path(python_interpreter_config Python3::Interpreter CONFIGURE)
# ...
install(CODE "execute_process(COMMAND ${python_interpreter} setup.py ...
The same workaround is already used a little lower in the file
ament_cmake/ament_cmake_python/cmake/ament_python_install_package.cmake
Lines 189 to 197 in 2bf27ce
get_executable_path(python_interpreter_config Python3::Interpreter CONFIGURE) | |
# compile Python files | |
install(CODE | |
"execute_process( | |
COMMAND | |
\"${python_interpreter_config}\" \"-m\" \"compileall\" | |
\"${CMAKE_INSTALL_PREFIX}/${ARG_DESTINATION}/${package_name}\" | |
)" | |
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for this valuable hint. I adapted the code accordingly - sorry for the long delay.
Should be ready for merging now.
Signed-off-by: Robert Haschke <rhaschke@techfak.uni-bielefeld.de>
04c9f78
to
30db879
Compare
Is there any chance that this PR will get merged? |
This PR implements various improvements to
ament_python_install_package
:SCRIPTS_DESTINATION
argument optional as suggested in Make ament_python_install_package() install console_scripts #328 (comment)By using
install(CODE ...)
to directly generate into the target location we can still avoid creating an empty target folder.Generating into build folder and (potentially) creating a symlink from this build to the install folder, wasn't good practice anyway.
SCRIPTS_DESTINATIONs
This is, for example, required by
xacro
, which installs tolib/xacro
andbin
If this got merged, I will create backport PRs for Foxy and Galactic.