On 30.01.2013 21:47, Dirk Thomas wrote:
> For catkin that means it is based on CMake because that is one of the 
> most used tools for building C++.
> And therefore catkin aims to keep the standard CMake workflow working 
> - so the user can build stuff just as he does with vanilla CMake.
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.

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.

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.



On 30.01.2013 21:18, Jonathan Bohren wrote:
> 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.
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.

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.

> Then have commands like "catkin loadws" to source .catkin/devel/setup.sh

We cannot prevent users from creating such scripts that wrap source 
commands, and sharing those scripts. ROS is a community of users as well 
after all. However each new command layer indeed requires explanation 
and maintenance. I am mostly bothered about very repetitive and very 
cumbersome actions by the user. Something that is only done once a day 
and rather quickly done using tab completion might not be the ideal 
candidate for scripted support.

> 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.
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.

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.

cheers,
   Thibault