Re: Issues!

From: David Abrahams (gclbb-jamboost_at_[hidden])
Date: 2003-05-22 05:03:49

Vladimir Prus <ghost_at_[hidden]> writes:

> 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? 

It was just a guess.

> "build.bat" has "x" bit only in M3 packages. In fact, I don't think
> you can change permissions in CVS.

OK. Not sure what the problem was, then. I still have the 

mv yyacc yyacc.x

in my command history which caused the build to succeed.

>> 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)

Sorry, I meant "generators.select-dependency-graph".

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

Yep.

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

Yes, good point.

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

Right. Lucky.

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

I think both of these are true, by different criteria. The first
one, because the paths are shorter and the same sources are consumed.

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

I think as I mentioned in my previous post that composing generators
are fine as long as they appear only once on any path from source to
target. I still believe that. Some systems require you to
post-process a DLL in order to get an IMPLIB... why should that be a
problem?

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

No, I think we should be smarter about which generators are chosen.

> The second bug also exists, I think.

Agreed.

I had other questions in my post which you still haven't
addressed... (e.g. about "name").

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com