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
(text/plain)