On Wed, Jan 30, 2013 at 2:13 PM, Jonathan Bohren <span dir="ltr">&lt;<a href="mailto:jonathan.bohren@gmail.com" target="_blank">jonathan.bohren@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div class="im">On Wed, Jan 30, 2013 at 3:47 PM, Dirk Thomas <span dir="ltr">&lt;<a href="mailto:dthomas@willowgarage.com" target="_blank">dthomas@willowgarage.com</a>&gt;</span> wrote:<br></div><div class="gmail_extra">

<div class="gmail_quote"><div class="im">

<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">(even if you can with the current catkin by passing in custom folder for build/devel/install).<br>




<br>
Anyway we are looking for ways to make catkin_make have a bit more sugar to make that tool easier and more convenient to use.</blockquote><div><br></div></div><div>Then what if we support the following new but thin, tools for people who want to use catkin_make instead of full-on-catkin but don&#39;t like having to jump around their filesystem in the standard CMake workflow.</div>

</div></div></div></blockquote><div><br></div><div>The only improvement this proposal has is that it can be done from the source space.  I agree with Dirk that hiding files in a .catkin folder is not desirable, visibility is important, especially for people who are unfamiliar with this development model.</div>

<div><br></div><div>As for the source space folder, aka `workspace/src`, my opinion is that it is an improvement on having all of the packages in the root of the workspace. The reason I say that is that having the source code not be direct peers of the build, devel, and install spaces makes searching it with simple tools easier.  For example:</div>

<div><br></div><div># I can search just the pristine source space</div><div>$ cd ~/workspace/src</div><div><div>$ grep -r &quot;#ifndef ROSCPP_ROS_H&quot; .</div><div>./roscpp/include/ros/ros.h:#ifndef ROSCPP_ROS_H</div>
<div>
<br></div><div># Or I have to search the build and install and devel spaces too</div><div>$ cd ~/workspace</div><div>$ ls ~/workspace</div><div>src</div><div>build</div><div>devel</div><div>install</div><div>$ grep -r &quot;#ifndef ROSCPP_ROS_H&quot; .</div>

<div>./install_isolated/include/ros/ros.h:#ifndef ROSCPP_ROS_H</div><div>./src/roscpp/include/ros/ros.h:#ifndef ROSCPP_ROS_H</div></div><div>./build/....</div><div><br></div><div>You can work around this with excludes and other things, but this is a distinct advantage from my point of view. On the other hand I can&#39;t think of a reason for having the source packages be direct peers of the other spaces...  The only real reason is that currently the tool doesn&#39;t let you run catkin_make from anywhere in the workspace, but we are proposing to fix that.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> Note I use the current catkin_make script in `catkin init` to illustrate what that should do. Also note that this preserves what are basically pass-through calls to cmake and make </div>



<div><br></div><div>`catkin init`:</div><div>    mkdir -p .catkin/build .catkin/install .catkin/devel</div></div></div></div></blockquote><div> </div><div>This line would not be needed.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>    catkin_make  --build .catkin/build --src . --devel .catkin/build</div></div></div></div></blockquote><div> </div><div>This would be: `catkin_make --build .catkin/build --src . -DCATKIN_DEVEL_PREFIX=.catkin/devel`</div>

<div><br></div><div>The devel prefix is defined purely in cmake and we intended it that way. Also, just as a note, you don&#39;t want to point your devel and build space to the same folder, this would be like installing your normal cmake project to your cmake build folder.</div>

<div><br></div><div>Also, `catkin_make` would have run cmake and make already so the follow commands are not necessary unless you want to run them explicitly.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>`catkin cmake [cmake_args]`:</div>

<div>    cd /path/to/ws/.catkin/build &amp;&amp; cmake /path/to/ws $cmake_args</div><div>`catkin make [make_args]`:</div><div>    cd /path/to/ws/.catkin/build &amp;&amp; make $make_args</div><div>
<div>
`catkin ninja [ninja_args]`:</div><div>    cd /path/to/ws/.catkin/build &amp;&amp; ninja $ninja_args</div></div></div></div></div></blockquote><div> </div><div>I wouldn&#39;t think we would support ninja since cmake doesn&#39;t come with a native generator for it. Even then we don&#39;t support the other generators that cmake provides.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><div class="gmail_quote"></div>

</div></div><div><div class="gmail_quote"><div>`catkin source`:<br></div>

</div></div></div><div>    source /path/to/ws/.catkin/devel/setup.sh</div></div></div></blockquote><div><br></div><div>How should it know which space to source?  If I just ran `catkin_make --install` on a clean workspace I now have a valid devel and install space of which I could source either.  Would this information be stored in the marker file or ...?</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><br></div><div>Also it&#39;s worth noting that the current version catkin_make ignores the &quot;--devel&quot; argument.</div>

</div></div></blockquote><div><br></div><div>It does not have a `--devel` argument.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">

<div class="im">

<div><br></div><div>-j</div><div><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><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>
<br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>William Woodall<div>Willow Garage - Software Engineer</div><div><a href="mailto:wwoodall@willowgarage.com" target="_blank">wwoodall@willowgarage.com</a></div>