<div dir="ltr">On Wed, Jan 30, 2013 at 11:59 AM, Thibault Kruse <span dir="ltr"><<a href="mailto:kruset@in.tum.de" target="_blank">kruset@in.tum.de</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I raised some concerns over catkin_make convenience in a meeting, here are the results of the brainstorming. catkin_make is mostly a convenience wrapper to cmake/make, for usage with the catkin build system starting with ROS Groovy.<br>
<br>
The current catkin_make design was guided by the desire to have a consistent and self-explaining workspace layout for tutorials and novice users, a quick way to create workspaces, and a wrapper around cmake to reduce cumbersome typing of common -D options.<br>
<br>
In it's current state, catkin_make may not as convenient as it could be. Current quirks are:<br>
- the workspace/src folder in itself is not popular with everybody<br>
- it is inconvenient to have to cd into the workspace folder to invoke catkin_make<br></blockquote><div>+1 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- it is inconvenient that wstool commands work in the src folder and below only, currently, meaning another "cd" step<br></blockquote><div>+1 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- invoking catkin_make once with custom options (for build/src locations), and then again without options does not remember the last options, and retyping the options is also cumbersome.<br>
- cleaning up builds (make clean, make distclean) does not work too well and is cumbersome, more support would be nice<br>
<br>
Since REP128 (<a href="http://ros.org/reps/rep-0128.html" target="_blank">http://ros.org/reps/rep-0128.<u></u>html</a>) does not make a strong effort to justify the design it defines, we have to also look at some use cases and find justifications.<br>
<br>
- We can consider 3 types of user groups who may want to use catkin_make<br>
-- total noobs: Those need one source space, one build configuration and that's it </blockquote><div>+100 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
-- advanced programmers: Those may typically have 2 build configurations, one with debug settings, one with performance optimized settings<br>
-- power users: Those may have a large number of build configurations for the same workspace, for cross compilation experiments and such<br>
I assume the toplevel "src" folder allows to have some cleanliness in particular for power users, having multiple build, devel and install spaces at the workspace root level, and packages one level below. On the other hand, I assume it would be similarly clean if all build, devel and install spaces were stored away in workspace/builds, and packages else reside in the workspace root.<br>
<br>
- catkin workspaces are used by several people using symbolic linking (for convenience, and maybe due to known limitations of catkin overlaying)<br>
<br>
- catkin also does env_caching, which needs to be taken into account for sequences of buildspace creation actions<br>
<br>
- there is also catkin_make_isolated, which currently creates a different folder layouts, maybe some consolidation could happen there as well<br>
<br>
<br>
<br>
So some design strategies that we came up with regarding more flexibility of invoking catkin_make and setting up workspace layouts according to personal preferences.<br>
<br>
<br>
Alternative "Marker-file":<br>
This idea involves placing a marker file at the workspace root, which can be used by catkin_make as point of reference when invoked in a subfolder (and maybe also by roscd without arguments). To support invoking catkin_make without arguments with custom paths, the marker file could have content that defines build configurations, e.g. the last one that was specified. For users that typically have multiple build configurations, this could be extended to have differently named configurations. Probably cmake already caches options for us, so really what could be stored in the marker file would be the path to a build space. However build-spaces get nuked regularly (since we have no great "clean" target), so duplication of information might still make sense in the marker file (unless we find a nice "clean" command).<br>
Such a markerfile might also be made compliant with wstool, one way or the other. The disadvantage here is that some additional infrastructure is require, to be maintained.<br>
<br>
Alternative "Build Env Switching":<br>
This idea involves switching build configurations (rather than workspaces), meaning every build folder gets it's own file to source, like "setup.sh", though a different name might be better. Such a file would declare an env variable pointing to the build folder, and invoking catkin_make from anywhere would invoke cmake/Make in the folder of the env var (if set). Disadvantages are that this is less transparent to the user, requires the user to know about this setup file as well, and encourages the bad habit of reusing the same shell for different build environments.<br>
<br>
So this is just brainstorming, and anyone who feels passionately enough about catkin_make is welcome to contribute ideas, opinions, (informal) votes. The next steps could be to write prototypes and a REP. Once we start doing that, we'll probably take the discussion to the ROS Buildsystem SIG, but I'd be happy to get some feedback by mere catkin users.<br>
</blockquote><div><br></div><div style>Thibault,</div><div style><br></div><div style>Thanks for bringing up this design discussion! I'd also like to see the catkin workflow made simpler and more intuitive for those not familiar with FHS and the nitty-gritty of CMake. I have a bunch of thoughts / opinions / feedback from using rosbuild and catkin, as well as explaining catkin to my colleagues who are used to rosbuild.</div>
<div><br></div><div style>Whenever I'm using catkin, I feel like it's been designed primarily for the people who want to release and/or install code, and focuses on solving those problems more than it does make it convenient for the student or researcher who only ever builds his or her code from source.</div>
<div style><br></div><div style>What if, given a workspace, we could just have a bunch of source packages and then we could put all of the "build", "devel", and "install" directories under a hidden directory called ".catkin". Then, inside of the ".catkin" directory we could have a config.yaml file. This combination of ".catkin/config.yaml" will act as the marker file, and keep the workspace focused on the source code instead of the buildsystem. <br>
</div><div style><br></div><div style>Then a workspace approaches the simplicity of a rosbuild workspace managed with rosws.</div><div style><br></div><div style> - my_project_workspace/</div><div style> - .catkin/<br>
</div>
<div style> - build</div><div style> - devel</div><div style> - install</div><div style> - my_package_a...</div></div><div> - my_package_b...</div><div style> - some_repo_x</div><div style> - some_package_c</div>
<div style> - some_package_d</div><div style><br></div><div style>Then have commands like "catkin loadws" to source .catkin/devel/setup.sh (this also becomes more cross-platform than manually sourcing one of the several shell scripts in your "devel" directory. I feel like if users are going to be required to maintain this structure in their workspaces, then it should be done with tooling like the philosophy behind rosws/wstool.</div>
<div style><br></div><div style>The main effect of this is that it brings the focus back onto the source code, as opposed to the whole catkin infrastructure. I definitely appreciate the huge amount of work that has gone into catkin, but I don't want to have to be messing around with these additional layers of directories. I want to be focusing on robotics code, and I just want whatever build system I'm using to stay in the shadows and do its thing. </div>
<div style><br></div><div style>Rosbuild excels in this regard: as long as packages are under the $ROS_PACKAGE_PATH, you can call "rosmake some_package" from anywhere, and it just builds the code, and then to launch something you use rosrun or roslaunch, and you don't care about the location of the built targets. I feel like ROS already has an abstraction layer in place that catkin could be dropped into so that by I???turtle, you can just call "rosmake" to invoke catkin from an arbitrary place like directory, and you wouldn't even know it's using catkin.</div>
<div style><br></div><div style>I understand that there are a ton of more advanced things that we'd like to do (and new patterns that catkin enables) but I think it would be unfortunate it we lost the ease-of-use of rosbuild.</div>
<div style><br></div><div style>What do others think?</div><div style><br></div><div style>-j</div><div style><br></div>-- <br><div style="font-family:arial,sans-serif;font-size:13px"><span style>Jonathan Bohren</span></div>
<div style="font-family:arial,sans-serif;font-size:13px">
<span style>PhD Student</span></div><div style="font-family:arial,sans-serif;font-size:13px"><span style>Dynamical Systems and Control Laboratory</span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><span style>Laboratory for Computational Sensing and Robotics</span></div><div style="font-family:arial,sans-serif;font-size:13px">
<span style>The Johns Hopkins University</span></div><div style="font-family:arial,sans-serif;font-size:13px"><span style><br></span></div><div style="font-family:arial,sans-serif;font-size:13px">
<font style color="#000000"><span title="Call with Google Voice"><a href="tel:%28707%29%20520-4736" value="+17075204736" target="_blank">(707) 520-4736</a></span></font></div><div style="font-family:arial,sans-serif;font-size:13px">
<font style color="#000000"><a href="mailto:jbo@jhu.edu" target="_blank">jbo@jhu.edu</a></font></div>
</div></div>