Hi all,

with the latest release to public ROS repositores, rosmake in fuerte
and groovy now as default uses multiple jobs to compile, which can
lead to a significant speedup.
This fixes a bug, as this was the intended behavior for rosmake all the 
time.
With the fix, the --pjobs option to rosmake should now also have the 
intended effect.

This post is to notify electric users about the fix to rosmake, as the
fix is not going to be released to electric or earlier ROS distributions.
Basically rosmake invokes make, and to use multiple cores, it's best to
be invoked with -jX -lX, where for X people often use the number of CPU 
core.
The variant "-j -lX" is dangerous as it can spawn a very high number of 
jobs.

Here is a unified diff of the change:

--------------------- tools/rosmake/src/rosmake/engine.py 
---------------------
index 12787a0..e4fe308 100755
@@ -387,13 +387,12 @@ class RosMakeAll:
          """
          local_env = os.environ.copy()
          if self.ros_parallel_jobs > 0:
-            local_env['ROS_PARALLEL_JOBS'] = "-j%d -l%d" % 
(self.ros_parallel_jobs, self.ros_parallel_jobs)
+            local_env['ROS_PARALLEL_JOBS'] = "-l%d" % 
self.ros_parallel_jobs
          elif "ROS_PARALLEL_JOBS" not in os.environ: #if no environment 
setup and no args fall back to # cpus
              # num_cpus check can (on OS X) trigger a Popen(), which has
              #the multithreading bug we wish to avoid on Py2.7.
              with _popen_lock:
-                num_cpus = parallel_build.num_cpus()
-                local_env['ROS_PARALLEL_JOBS'] = "-j%d -l%d" % 
(num_cpus, num_cpus)
+                local_env['ROS_PARALLEL_JOBS'] = "-l%d" % 
parallel_build.num_cpus()
          local_env['SVN_CMDLINE'] = "svn --non-interactive"
          cmd = ["bash", "-c", "cd %s && %s "%(self.get_path(package), 
make_command()) ] #UNIXONLY
          if argument:

As you can see, the --pjobs argument to rosmake had no effect neither
(that's what goes into self.ros_parallel_jobs), but the 
ROS_PARALLEL_JOBS env var should work.

Electric users can make this change manually in
/opt/ros/electric/ros/tools/rosmake/src/rosmake/engine.py.
(I think that would also involve removing engine.pyc from that folder).
Electric users can also get this by installing Electric from source when
using the raw electric github branch ('ros-1.6') of the "ros" stack (not 
the released tar).
Cturtle and Diamondback users have to manually find the location if they 
want this fixed.


cheers,
   Thibault




PS:
There is a small story for this bug. It was introduced in May 2011 
(01/05/11)
into ROS CTurtle and Diamondback as a failed attempt to prevent CPU
overload making the system slow down during compilation [1]. At the
time it was noted that the approach was flawed, see the ticket discussion,
but it was overlooked to change the patch.

I noticed the bug in August 2012 (08/24/12) when I noticed catkin was
faster than rosmake by more than what could be accounted for by the
actual differences between catkin and rosmake. I reported this in both
the issue tracker [2] as well as the ongoing discussion on catkin [3]. I did
not get immediate attention for this, so after a few weeks I wrote a
mail to Tully, and then a patch was made on 09/19/12 to the Electric
and Fuerte branches in the repository.

However the patches to Electric and Fuerte were never released
(the "ros" stack was not rereleased), and Groovy was released without 
the fix as well.
I discovered this in February (02/19/2013)
and wrote a mail to Tully, then raised it in a platform group meeting.
Dirk discovered that the patch should be changed to prevent mass spawning
of build processes, and added another patch to prevent this to Fuerte
and Groovy [4].

Given this fix, the speed advantage of catkin over rosbuild is reduced, so
opinions about catkin being much faster than rosbuild might be taken with a
grain of salt, though catkin remains somewhat faster than rosbuild.



[1] https://code.ros.org/trac/ros/ticket/2920
[2] 
https://groups.google.com/d/msg/ros-sig-buildsystem/sBgxP7DsDko/nRIR5j917igJ
[3] https://code.ros.org/trac/ros/ticket/4036
[4] https://github.com/ros/ros/issues/4