[jamming] Is -j broken, or is it just me?

Chuck Homic chuck at vvisions.com
Tue Jun 15 14:39:10 PDT 2010

On 4/29/2010 11:14 AM, Chuck Homic wrote:
> On 4/28/2010 3:08 AM, Ingo Weinhold wrote:
>>> Do you/Diane have actions where there are multiple output targets on
>>> actions? There is a known issue whereby jam will not wait for the 2nd
>>> output target, that is, if it is a dependent for something else.
>> That is indeed the case in the example I'm thinking of. The Jamfile [1]
>> generates a header/source file pair and sometimes jam starts the 
>> compilation
>> actions for the source file (builtins.c ->  builtins.o) before it has 
>> been
>> generated.
>> Is a fix or work-around known for the bug?
> I have a patch to fix this exact problem.  I'm securing permission 
> from my company to release it, so stand by.
>  -Chuck

Is there a prohibition on sending attachments to the list?  I sent a 
diff as an attachment to the list some time ago, and I have not yet seen 
it.  Here it is as a link instead: 

And here is the original message I sent with the attachment:


I'm fairly confident that many will take issue with the coding style.  
Particularly the use of the coroutine simulator.  Feel free to rewrite 
the code if you have a problem with that aspect of it.  (I also haven't 
checked if it patches cleanly against a pristine source tree.  My studio 
has a number of other silly changes to Jam that I stripped from the 
patch manually, so please let me know if there's problems building it.)

The basic idea is that actions can have multiple destination targets, 
but during dependency analysis, Jam only looks at targets and their 
dependencies (not actions).  As a result, once a target is cleared to 
build, it runs the associated action, even if that action has other 
targets that are not ready to be built.

The "dependency iterator" changes that logic wherever the dependencies 
of a target are being considered, to also consider the dependencies of 
other targets of the same action.  I have called multiple targets of the 
same action "codependent targets."  By iterating through all 
dependencies of all codependent targets, we are assured that the action 
doesn't run until all the dependent targets are built.  QED.

I changed the debug output for -dd so that it says "Depends" for direct 
(normal) dependency, but "CoDepends" for targets considered for their 
codependencyness.  That can help you determine if this patch is actually 
helping (aside from whether or not your build actually works).  I can 
assure you we've been using this for three years (I just noticed that 
today is this patch's anniversary!) with some really complicated 
dependency scenarios, and it's worked fine, with no more "double builds" 
(except for legitimate jamfile errors).

And of course: This patch is donated to the public domain. There is no 
warranty of any kind.  I'm not responsible for it, nor is my company.  
If you patch it in to your code, it could fix your dependency problem, 
or reformat your hard drive, and it's up to you to determine which will 
happen and live with the consequences.

That said, I hope this helps you and make you less frustrated.


More information about the jamming mailing list