Re: [jamboost] Issues!

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 
builds.

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
> bug.

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 
good. 

> 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 
allowed.

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
situations.

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.

- Volodya