-
Notifications
You must be signed in to change notification settings - Fork 280
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
Find python path properly for installed underlays. #397
Conversation
@wjwwood Can you think about side effects of such a change? |
As long as he iterates in the correct order, I see no problem with adding these to the Python path, either:
The last point is the only one of concern, so as long as the workspace order is correct then it should be fine. How does this method handle the environment hooks? Are they needed for build time? |
I haven't had any need for the environment hooks with our build scripts yet. I suppose there could be a need sometime in the future, but maybe just worry about that if at some point it's needed. |
@stonier the environment hooks sets the ROS_PACKAGE_PATH, ROS_ROOT, and ROS_DISTRO environment variables (among other things). Those are important if you are using the ROS tools at a later point. |
Good point. I'll check out what's going on in there. |
Some results from testing: All generate_setup_cached.py
setup_cached.sh
Compare that with a setup_cached.sh generated the usual way from sourcing
The only important difference is that the former creates alot of new environment variables (naturally, since the environment was almost blank) and the latter just modifies variables that were sourced. |
This is a follow on from ros#397
Closing this and following up in #406 |
This is a follow on from ros#397
This is a follow on from ros#397
Related to ros#397.
This is the only change I need to work with underlays that are completely defined by
CMAKE_PREFIX_PATH
in an initial cache rather than environment variables persistently set by sourcing underlaysetup.xxx
scripts every time you cmake/make.See parallel email thread in ros-sig-buildsystem. I think it would be very convenient (if for us, then I'm sure others as well) to support this and it doesn't break support of the former manual sourcing style.