|
Boost-Build : |
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
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