boost jam problem with parallel builds

[alx_s]

OK, this bug makes my life miserable for a long, long
time. :)

In short, if I have an action which updates more then
one target then I have problem with parallel build.

Attached is a simple testcase. Just run 'jam -j2' and
you can notice that target 'g2.generated' is been used
before it is updated (created).

The testcase has just 2 rules - 'Gen' models generating
2 files which are used by 'Use'.
The testcase doesn't actually create any files, but
that doesn't matter. Jam works with targets, not files.

The last line in the Jamfile is a workaround. If you
uncomment it, the test works fine.

I spent some time trying to find the reason and to fix
the bug, but succeed only in the first part.

I can discuss it in more details with someone
interested in fixing it. I just didn't get enough time
to fix the bug by myself.

[René Rivera]

Logged In: YES 
user_id=33595

As intended. The dependency graph of your example looks
something like:

u1.user -> g1.generated
u2.user -> g2.generated

The fact that g1.generated and g2.generate are produced by 1
action is irrelevant. You need to change the code so the
dependency graph looks like:

u1.user -> g1.generated
u1.user -> g2.generated
u2.user -> g1.generated
u2.user -> g2.generated

Which you can do by changing the Use rule invocations to:

Use u1.user : g1.generated g2.generated ;
Use u2.user : g1.generated g2.generated ;

HTH.

[alx_s]

Logged In: YES 
user_id=445009

As intended what? I didn't get you.

You are right about dependency graph. It does look like:

u1.user -> g1.generated
u2.user -> g2.generated

And you are right that the fact that g1.generated and
g2.generate are produced by 1 action _should_ be irrelevant.
But it's not. That is the problem. If they are produced by
one action, then I have a problem with parallel builds. If
they are produced by separate actions - all is fine.

Just look at the line you wrote: 

u2.user -> g2.generated

That means that g2.generated should be updated before
u2.user. Right? But this is not the case if parallel build
is used. Changing dependency graph as you suggested helps,
but it doesn't fix the problem. It is just a workaround.

Regards,
Alexey Sarytchev

[René Rivera]

Logged In: YES 
user_id=33595

Hm, sorry I see what you mean now. I though you where
talking about a new problem. But it's just one of the
existing bugs/limitations of the original Perforce/Jam. See
the "BUGS, LIMITATIONS" section of
http://public.perforce.com/public/jam/src/Jam.html
(http://64.233.187.104/search?q=cache:fDuhra5lsswJ:public.perforce.com/public/jam/src/Jam.html+BUGS+LIMITATIONS&hl=en).

Yea, I know it's not much of a consolation :-( I can't
promise a fix any time soon, as I don't see any generic easy
solution, but I'll work on it.

[alx_s]

Logged In: YES 
user_id=445009

Yes, I know it a known bug in the original Jam. :)
It just looks like nobody is working on it there. So I
decided to submit it for boost jam as it looks like it is
more actively developed. And did that with a simple testcase
which shows the problem. It didn't looked too hard to fix
for me when I figured out what was the cause, but just
required a better knowledge of the some sort of state
machine used by Jam to update targets. So I thought maybe
someone with that knowledge could finally fix it.

Regards,
Alexey Sarytchev

[René Rivera]

Original testcase from SF tracker.