Boost C++ Libraries: Ticket #431: boost jam problem with parallel builds

René Rivera — Sun, 23 Oct 2005 16:03:30 GMT

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.

status changed

alx_s — Sun, 23 Oct 2005 18:50:37 GMT

status assigned → closed

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 — Sun, 23 Oct 2005 19:43:31 GMT

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 — Sun, 23 Oct 2005 21:13:58 GMT

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

component changed

René Rivera — Fri, 11 May 2007 06:34:59 GMT

component None → bjam

version, description changed; severity set

René Rivera — Mon, 21 May 2007 15:24:58 GMT

version None → Boost.Jam 3.1.14
description modified (diff)
severity → Problem

attachment set

René Rivera — Sun, 16 Sep 2007 22:41:48 GMT

attachment → Jamfile

Original testcase from SF tracker.

milestone set

René Rivera — Mon, 17 Sep 2007 01:29:55 GMT

milestone → Boost.Jam 3.1.15

status, resolution changed

René Rivera — Mon, 17 Sep 2007 08:33:42 GMT

status assigned → closed
resolution Accepted → fixed