[Documentation] [TitleIndex] [WordIndex

API review

Proposer: Troy Straszheim

While attempting to implement REP 102; my changes quickly got out of hand and would have broken lots of stuff (for instance, all of the tutorials).

Brian asked me to start this API review as a way of iterating towards a possible "Rosbuild 2".

Currently I have a list of sketched "Buildsystem Desiderata" that are a mixture of use cases and coding standards, indended to:

Buildsystem Desiderata (Troy)

Backward compatibility (Brian)

There's a LOT of existing code that uses the existing build system. To avoid massive breakage, we should provide a gentle migration path. We should continue to support the existing build system and workflow, with deprecation warnings as appropriate, for example:

install target Desiderata

(comments from the "LAAS infrastructure team")

Deb-building Support (Jeremy)

More desiderata

kwc

Python

Python users should generally not notice any new build infrastructure. I should be able to checkout a package, modify the script that I'm running, and immediately run it without any building, copying, etc... As one example, I should be able to have two windows: an editor and a running interpreter, and keep reloading the module in my interpreter as I edit it.

Stacks vs. Packages

There is demand to release packages individually, but this is a major configuration management issue. We have to run approximately 12 regression jobs (devel/released/pre-release * lucid/maverick * i386/amd64) per stack on unstable, and 24 per stack in cturtle. These tests ensure that a stack actually installs, and they are what enables us to not break cturtle/unstable when doing new releases. Given that these regression jobs frequently find issues, it appears that they are necessary. From a configuration management point of view, it's not possible to scale this easily.

An alternative that we have yet to explore is unary stacks, where you can place both a stack.xml and manifest.xml in the same directory. This has some consequences for the build system and the rest of the ROS tools, but should be do-able. I think this approach balances the tension between packages that are truly standalone vs. the stacks that truly should be bundled.

(Josh)

I'd like to see all build-specific information removed from the manifest. Most of it (everything but dependencies) should be generated at build time into some other file (which cannot be pkg-config, since as far as I know it only supports C/C++).

Also, all the standard exported compile flags should be specified as their higher-level component (such as "include directories", "library", etc.) rather than the actual flag (-I<path>, -lfoo, etc.)

rosbuild design goals discussed at Willow Garage meeting 13 Dec 2010

TODO


2023-10-28 12:59