Re: [Boost-build] Problem with ambiguity error

From: Daniel Einspanjer (deinspanjer_at_[hidden])
Date: 2006-03-10 13:11:11

"Vladimir Prus" <ghost_at_[hidden]> wrote in message 
news:200603101238.29652.ghost_at_cs.msu.su...
> I'm sorry, but I'm completely lost in all those transformation. Maybe we
> should go back and you'll describe:

I am truly sorry that I've caused you confusion with this thread. I really 
do appreciate your help and your willingness to take one more crack at it.

First off, please note that the test case zip file I provided previously in 
the message thread demonstrates the desired output if you edit the Jamroot 
to switch around the two imports according to the comments.  You can then 
run bjam or bjam <atarget> and see what I'm expecting as output. I started 
this whole thread because it seemed bad to me that having the imports one 
way caused it to work perfectly (AFAICT), but having them reversed caused 
ambiguity errors.

>   1. What are new types of sources type you need in your project, what
>      are extensions for those types.

I have two new source types:
CSCONFIG with the extension ini
and
CUSTOMERINFO for which I do not specify a source extension because the only 
possible source file of that type is named "defaultcustomerinfo.cpp".
I rely on a cast to try to make BB understand that this one particular CPP 
file is in fact a CUSTOMERINFO file.  There is no other file that I would 
ever want to be considered a CUSTOMERINFO file, source or target.

>   2. What are the transformations between those types. For each
>      transformation, state:
>      - which source types it takes, and what number of each type
>      - what is the output

I have two potential transformation actions for CSCONFIG.
CSCONFIG.merge -- if the target is another csconfig ini and the sources are 
two csconfig.ini, then this action merges them together.
CSCONFIG.transform -- if the target is a cpp, and the source is a single 
csconfig ini, then this action will transform the ini into the desired cpp. 
In my actual code, the tool is compiled into an executable by BB and passed 
in as a <built-tool> feature and dependency. In the testcase, I represented 
the transform action as just a straight echo of the ini file for 
simplicity's sake.

I have one possible transformation action for CUSTOMERINFO.
CUSTOMERINFO.transform -- The only possible target should be a normal cpp 
file that can then be used in further targets to be transformed into an obj 
and eventually into an exe or lib.  The only possible source should be a 
single file, "defaultcustomerinfo.cpp" which I use the [cast] rule on to 
make it appear to BB as a CUSTOMERINFO source instead of a normal CPP.  The 
action uses sed to replace a string in the file with the name of the 
customer so that our code knows the customer for which it was built.

The cpp generated by CSCONFIG.transform should just be a normal cpp. I would 
never want CUSTOMERINFO.transform to touch it.

>   3. Please specify overall sequence of transformation you want.

csconfig csconfig-merged.ini : csconfig-defaults.ini 
csconfig-<acustomer>.ini ;
    -- this should invoke the CSCONFIG.merge action to concatenate the two 
source ini's into a single merged.ini.

cpp customercsconfig.cpp : csconfig-merged.ini ;
    -- this should invoke the CSCONFIG.transform action to convert the ini 
into a normal cpp file, able to be used in lib or exe targets.

# Note the cast arguments might not be perfect here, I'm just typing them 
from memory
cpp customerinfo.cpp : [ cast _ customerinfo : defaultcustomerinfo.cpp ] ;
    -- this should invoke the CUSTOMERINFO.transform action to run the 
source through sed generating a normal cpp able to be used in lib or exe 
targets.

I hope this new attempt at explanation is more clear than my muddled 
attempts before. Thank you for your time,
Daniel Einspanjer