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

roslisp: single fasls location for each package causes errors when switching ros releases #6

Open
130s opened this issue Jan 9, 2013 · 1 comment

Comments

@130s
Copy link
Member

130s commented Jan 9, 2013

Migrated from https://code.ros.org/trac/ros/ticket/3716
Reported by: kruset Owned by: bhaskara
Priority: minor
Last modified ago: Mar 2012


roslisp fasls are compiled to ~/.ros/roslisp/packagename. This means when switching e.g. between diamondback and electric, that the wrong fasls can get loaded. Instead, fasls should go and be fetched from specialized locations, like ~/.ros/roslisp/path/to/file

Current workaround: delete fasls in ~/.ros/roslisp on each switch

@130s
Copy link
Member Author

130s commented Jan 9, 2013

Changed 15 months ago by bhaskara

I see the problem but don't understand your solution. Can you give an example of the specific paths that would be used?

Changed 15 months ago by kruset

Fasls for ROS package /opt/ros/electric/stacks/common_msgs/geometry_msgs would go into ~/.ros/roslisp/opt/ros/electric/stacks/common_msgs/geometry_msgs

/opt/ros/diamondback/stacks/common_msgs/geometry_msgs would go into ~/.ros/roslisp/opt/ros/diamondback/stacks/common_msgs/geometry_msgs

/home/username/work/ros/sandbox/common_msgs/geometry_msgs would go into ~/.ros/roslisp/home/username/work/ros/sandbox/common_msgs/geometry_msgs

Changed 15 months ago by kruset

Hm, actually this still does not quite help. When switching between electric and diamondback the fasls at

~/.ros/roslisp/home/username/work/ros/sandbox/common_msgs/geometry_msgs 

could still conflict. So it would be even better to combine ROS_ROOT and path/to/file. That still leaves ambiguity for manually switching sbcl versions, so if we can also encode sbcl version, even better. Like: ~/.ros/roslisp/geometry_msgs/opt/ros/electric/sbcl-1.0.50/home/username/work/ros/sandbox/common_msgs/geometry_msgs The path could be somewhat reduced without too much risk by replacing "/opt/ros/electric" with just "electric" and starting at ~ for local files.

e.g. ~/.ros/roslisp/geometry_msgs/electric/sbcl-1.0.50/work/ros/sandbox/common_msgs/geometry_msgs

better ideas?

Changed 15 months ago by moesenle

Actually, I don't see that as an issue. Using the same package with different ROS distros at the same time is always a bad idea and you can run into all different kinds of inconsistencies not only with roslisp. Normally, I think users have one checkout per distro and not one checkout for all distros.

I think we shouldn't complicate this too much and try to find the minimal working solution. Just using $ROS_HOME/roslisp/ is fine and the corresponding patch should be pretty straight forward. Also, encoding the sbcl version shouldn't really be necessary since we catch the 'incompatible fasl' error and trigger recompilation in that case anyway.

To summarize, the only case where I see problems are lisp packages that lie in /opt/ros, mostly messages. When the user uses multiple distros at the same time, we either need to have the fasls at distinct locations or make sure that they are recompiled whenever the distro is switched. Currently, we (I guess) sort of implement the latter case. This might lead to lot's of unnecessary compilations and depending on asdf might even cause problems when the file dates don't indicate that recompilation is necessary. That means we actually want the former case implemented.

I will have a look at the source code and see if I can provide a quick patch as soon as I find some time.

Changed 11 months ago by kruset

Given similar issues with rosjava, I suggested a solution of either making rosinstall set a different ROS_HOME for each distro/rosinstall location, or a new ros env variable for binaries that rosinstall would set, leaving ROS_HOME fixed for non-conflicting data.

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

No branches or pull requests

1 participant