Issues!

From: David Abrahams (dave_at_[hidden])
Date: 2003-05-21 15:17:21

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.

2. generators.try-one-generator is accessing a variable from an
enclosing scope called $(results). I'm fairly certain this is a
bug.

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.

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
;

 --=-=-= Content-Type: text/x-patch
Content-Disposition: attachment; filename=foo.patch

diff -rdbu c:/boost/tools/build/new/builtin.jam c:/boost/tools/boost-build/new/builtin.jam
--- c:/boost/tools/build/new/builtin.jam	2003-05-16 07:05:41.000000000 -0400
+++ c:/boost/tools/boost-build/new/builtin.jam	2003-05-21 15:21:43.000000000 -0400
@@ -677,6 +677,6 @@
flags builtin.response-file FINDLIBS_ST <find-static-library> ;
flags builtin.response-file FINDLIBS_SA <find-shared-library> ;
flags builtin.response-file LIBRARY_PATH <library-path> ;
-register-linker builtin.response-file : OBJ SEARCHED_LIB STATIC_LIB IMPORT_LIB : RSP ;
+register-linker builtin.response-file : STATIC_LIB OBJ : RSP ;

diff -rdbu c:/boost/tools/build/new/msvc.jam c:/boost/tools/boost-build/new/msvc.jam
--- c:/boost/tools/build/new/msvc.jam	2003-05-21 02:20:43.000000000 -0400
+++ c:/boost/tools/boost-build/new/msvc.jam	2003-05-21 15:18:14.000000000 -0400
@@ -206,7 +206,7 @@
generators.register-linker msvc.link "" : RSP : EXE : <toolset>msvc ;
generators.register-linker msvc.link "" : RSP : SHARED_LIB IMPORT_LIB : <toolset>msvc ;

-generators.register-standard msvc.archive : RSP : STATIC_LIB : <toolset>msvc ;
+generators.register-standard msvc.archive : OBJ : STATIC_LIB : <toolset>msvc ;
generators.register-c-compiler msvc.compile : CPP : OBJ : <toolset>msvc ;
generators.register-c-compiler msvc.compile : C : OBJ : <toolset>msvc ;

@@ -287,7 +287,7 @@
actions archive 
{
if exist "$(<)" set _$(<:B)_="$(<)"
- $(.LD) /lib /out:"$(<)" %_$(<:B)_% @"$(>)"
+ $(.LD) /lib /out:"$(<)" %_$(<:B)_% "$(>)"
}
}
else # CYGWIN
 --=-=-= 

 You'll see that you get this:

---> e.lib ---> e.obj --> e.cpp
/
e.exe
\
---> d.lib ---> y.obj ---> y.cpp

instead of the expected:

---> e.obj --> e.cpp
/
e.exe
\
---> d.lib ---> y.obj ---> y.cpp

Some problems (e.g. with gcc) are prevented by this behavior in
generator.run:

# We don't run composing generators which are not given a name.
# This in effect, means that composing generators are runnable only
# at top-level of transofrmation graph, or if name is passed explicitly.
# Thus, we dissallow composing generators in the middle. For example, the
# transofrmation CPP -> OBJ -> STATIC_LIB -> RSP -> EXE won't be allowed 
# (the OBJ -> STATIC_LIB generator is composing)

But this rule seems somewhat arbitrary. What is the significance
of a generator's name, anyway? It seems a bit strange, to say the
least, to base dependency graph generation on the presence or
absence of a name. I notice that construct-without-cacheing never
passes a name. It's taken me a long time to trace where "name"
might be coming from, and it seems as though the only place might
be from the typed-target. There's something a little too twisty
about this logic.

I think the right way to solve the problem the rule addresses is
to say that along any path from sources to targets, only one
generator may be the kind which can accept "any number of sources"
(is that the meaning of "composing"? it keeps eluding me).

4. Can someone who knows what it means fix this comment, please?!

rule linking-generator ( id composing ? : source-types + : target-types + : 
requirements * )
{
# If composing is not specified, set it to true, which is "false" in Jam.

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