[jamming] Is -j broken, or is it just me?
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 
>> generates a header/source file pair and sometimes jam starts the
>> actions for the source file (builtins.c -> builtins.o) before it has
>> 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.
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