From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-05-22 02:47:58
David Abrahams wrote:
> I have a pile of problems to report; I need to go work on some other
> stuff before I can come back to it and I wanted to get it down in
> bits before I move along...
> 1. I did a clean checkout of the build directory and couldn't rebuild
> bjam from the NT shell with build.bat. It looks like it was trying
> to invoke the yyacc script instead of yyacc.bat. Haven't had time
> to confirm or diagnose this, but probably this has to do with the
> recent change to its permissions.
Ick! Seems like my almost clean NT box is not good for testing such kind of
problems --- it has no cygwin, no bison and no bash. No wonder, everything
BTW, what permissions do you mean? "build.bat" has "x" bit only in M3
packages. In fact, I don't think you can change permissions in CVS.
> 2. generators.try-one-generator is accessing a variable from an
> enclosing scope called $(results). I'm fairly certain this is a
In my copy, the rule does not use such variable at all. It uses variable
called "result" (note singular form), which is declared as local in that
rule. I don't have any local changes:
File: generators.jam Status: Up-to-date
Working revision: 1.48
Repository revision: 1.48 ..../new/generators.jam,v
Sticky Tag: (none)
Sticky Date: (none)
> 3. Even if you fix that, we never get to choose among several
> dependency graphs because of lucky circumstances and interactions,
> and currently there is no good criterion in place for making that
> choice. The circumstances in play are:
> a. No generator is allowed to run twice along any path from
> source to targets. I'm not certain this is a good rule - I
> can imagine cases where you'd want that - but I can live
> with it for now.
The rule is in place to prevent infinite looping --- which is certainly no
> b. likely short paths (OBJ) are listed first in the rules for
> building RSP files.
> If you apply the enclosed patch and then build a project with
> this Jamfile using msvc:
> lib d
> : y.cpp
> exe e
> : e.cpp d
Then you'll have library called "e" created and linked in exe called "e",
which is bogus behaviour. In fact, you can remove "d" target altogether, and
still get this behaviour. Hmm.... RSP can be created from STATIC_LIB and from
OBJ, so the generators code manage to convert e.cpp both to STATIC_LIB and
OBJ, and happily use them.
Without your patch applied, everything works okay, becase to create STATIC_LIB
you need to run response-file generator for a second time, which is not
I've two interpretations of this.
1. There's a bug in generators -- we should use only "OBJ".
2. There's a bug in generators -- we should not produce STATIC_LIB. In fact,
it's the *second* invocation of *composing* generators: builtin.response-file
is the first one, and msvc.archive is the second one. If you recall, we used
to have "allow-composing" parameter which controlled that. I still think that
composing generator in the middle of the search can only be used in special
And the funny thing is that I believe we have both of those bugs. If would not
be hard to produce an example where RSP takes OBJ and FOOBAR, and
FOOBAR can be produces from CPP by a sequence of two transformations.
In which case, CPP in sources will be converted both to FOOBAR and OBJ.
So the first bug exists -- we should error in this case, most probably. The
second bug also exists, I think.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk