<div dir="ltr">On Fri, Feb 1, 2013 at 6:07 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 30.01.2013 21:47, Dirk Thomas wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For catkin that means it is based on CMake because that is one of the most used tools for building C++.<br>
And therefore catkin aims to keep the standard CMake workflow working - so the user can build stuff just as he does with vanilla CMake.<br>
</blockquote></div>
This made me think of the separation between configure and build steps. Cmake has two separate commands for this, while catkin_make currently both wraps cmake and make invocations. Merging the arguments to both cmake and make into a single command might not be the right approach then.<br>
<br>
E.g. having catkin_cmake or catkin_configure to wrap calls to cmake, and catkin_make to wrap calls to make might be a better representation of the cmake workflow.<br>
<br>
Thought I would be happy to add to catkin_configure features that provide users with nice defaults for having both a debugging build configuration and an optimized build configuration without the user having to understand the details of cmake -D options or even c++ compiler settings first.</blockquote>
<div><br></div><div>Yeah, if we could basically use catkin_cmake and catkin_make to streamline development by giving users the capability to run cmake and make in the appropriate directories for the catkin workspace without actually having to navigate to them, that would be great.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
On 30.01.2013 21:18, Jonathan Bohren wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
</blockquote></div>
We can keep in mind having separate subfolders wrapping a build, devel and install space that belong together. That might be more useful than to have to manually manage this tripel of folders via naming conventions. The build, devel and install space are in my opinion far too prominent in the current workspace layout, given that to most users, it is the source that is most relevant as working material.<br>
<br>
Regarding using a hidden folder, I do see the problem with using find commands, but on the other hand users already benefit from using find commands that ignore hidden folders, such as to not waste time (and get undesired results) grepping through .git and .svn subfolders when searching through code. But I struggle to see this as a novice-friendly default as well, as it is so unlike cmake default usage.</blockquote>
<div><br></div><div>What if we just had two directories in a workspace: "catkin" and "src" (or catkin_build and catkin_src) and then it doesn't hide anything, is even more descriptive, and also satisfies Will's desires to keep the source in an isolated space. Then inside of catkin or catkin_build there is a build,devel,install or cmake_build,devel,install or something similar?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote></div>
The rosmake abstraction layer does not consider things like install targets and multiple build configurations. So while it might be technically feasible to circumvent catkin workspaces and build catkin packages with an extended rosmake, the benefit would probably not justify the effort. On the other hand building rosbuild projects as part of a catkin workspace might be something that is feasible using catkin_make_isolated. If feasible, that would be an easier sell to the catkin maintainers, in particular since we currently suffer that users have to set up two different workspaces using two rosinstall files to build all of ROS from source.<br>
</blockquote><div><br></div><div>I was moreso talking about just making catkin work like rosmake for novice users, where they'd have a catkin workspace, with catkin packages, and they could be inside some arbitrary directory and call "rosmake" but that would really just be an alias to "catkin_make". But this is just talking about the workflow more than it was any sort of backwards-compatibility.</div>
<div><br></div><div>That being said, it would definitely be great if you could put rosbuild packages in a catkin workspace.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As to having a build system that that does not get in the way of users, I believe catkin_make can get there after this discussion.<br></blockquote><div><br></div><div>Yeah, I'm confident it will get there!</div>
<div><br></div><div>Thanks!</div><div>-j</div></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"><a href="tel:%28707%29%20520-4736" value="+17075204736" target="_blank">(707) 520-4736</a></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>