Problem with ambiguity error

"Vladimir Prus" <ghostcs.msu.su> wrote in
message 
news:200602281125.35227.ghostcs.msu.su...
> On Monday 27 February 2006 00:14, Daniel Einspanjer
wrote:
>> "Vladimir Prus" <ghostcs.msu.su> wrote in message
>> news:200602261936.16703.ghostcs.msu.su...
>>
> Here's what's going on. First of all, to clarify your
intent, I suggest 
> you
> make all generators that now produce CPP type produce
CUSTOMERINFO type.
> as you're really producing customer info file, not
some random CPP. With 
> those
> change you get this pair of generators:
>
>      csconfig.transform: CSCONFIG -> CUSTOMERINFO
>      customerinfo.transform: CUSTOMERINFO ->
CUSTOMERINFO


The CSCONFIG and CUSTOMERINFO generators are completely
orthogonal. They are 
*only* related in the fact that their output file type
should be a normal 
CPP file.


> For a simplified use case:
>
>    cpp csconfig-customer.cpp
>       : # sources
>          csconfig-base.ini
>      ;
>
> you really get two possible transformation chains:
>
>   CSCONFIG -> CUSTOMERINFO
>   CSCONFIG -> CUSTOMERINFO -> CUSTOMERINFO
>
> In theory, the CUSTOMERINFO -> CUSTOMERINFO step can
be applied N times 
> more,
> but Boost.Build does not allow repating application of
the same generator 
> for
> obvious reasons.
>

I would hope to be able to get a transformation chain that
would be *only* 
CSCONFIG -> CPP.
I created CSCONFIG to handle the case where we have these
INI files (one 
which is always used and one selected based on the customer
feature) which 
get merged into a single ini file that is then fed through a
program that 
generates a standard CPP file which will follow the standard
compilation 
process from that point forward (CPP -> OBJ ->
LIB|EXE).  The merge is 
necessary only because the generation tool handles a single
ini file as 
input.

cpp customerinfo.cpp
    : # sources
        # This cast is needed so the customerinfo generator
        # gets called instead of the standard CPP generator.
        [ cast _ customerinfo : defaultcustomerinfo.cpp ]
    ;
I created CUSTOMERINFO to handle the (nasty) case where we
have this CPP 
file "defaultcustomerinfo.cpp" that contains a
string which must be replaced 
with the customer name.  The output of this generation is a
CPP file which 
from that point on should behave exactly as a normal CPP (as
above).  It 
would be bad (albeit hopefully a no-op) to run the
CUSTOMERINFO generator 
more than once.  Since I didn't know of a way to make a
generator that could 
operate on a file that already has other registered
generators, I registered 
a new type CUSTOMERINFO with no explicit extension that
inherited from CPP.

If CUSTOMERINFO is the source of all this trouble and there
is no way around 
it, I'll just change defaultcustomerinfo.cpp to be 
defaultcustomerinfo_cpp.src and register CUSTOMERINFO with a
src extension 
instead of using cast.  I got into this mess because I
thought that cast 
would allow me to port this portion without having to change
any of our 
existing build.


> And as a closing remark, the explanation why you get
the error with the
> current code, where target type of generators is CPP.
Here's the second
> transformation chains that Boost.Build finds:
>
>    1. customerinfo.transform has CPP as target type so
it's asked
>       to create CPP from CSCONFIG

Why would customerinfo.transform ever be asked to create a
CPP from 
CSCONFIG?

>    2. Source type of customerinfo.transform is
CUSTOMERINFO. There are
>       no generators for this type.

Why wouldn't it just treat the casted
defaultcustomerinfo.cpp file as the 
source it needs instead of looking for a generator to
transform it into 
itself?

>    3. Boost.Build tries generators for base types of
CUSTOMERINFO, in this
>       case -- CPP.
>    4. It finds the csconfig.transform
(CSCONFIG->CPP) generator.

So at this point, it tries to run the
defaultcustomerinfo.cpp file through 
the CSCONFIG -> CPP generator??  I don't think this
could be happening 
because the makecppconfig tool that turns a CSCONFIG.ini
file into a CPP 
would choke if passed in a CPP as its source.

>
> If Boost.Build did not do (3), this chain would not be
found, and you'd 
> have
> no ambiguity. However, this will prevent a handy
feature -- you can create 
> a
> new target type derived from an existing one and change
it's extension, 
> but
> all the generators will be inherited. Say, if you do:

I thought that the inheritance of generators worked in the
way you describe 
here. I was counting on it so that the CPP files my
generators outputted 
could then be consumed in the normal chain of CPP -> OBJ
-> LIB|EXE.

Finally, If this sequence of steps is what causes the
ambiguity error, why 
does reordering the imports fix the error and cause
everything to deliver 
the desired results (ini files turned into CPP and the one 
defaultcustomerinfo.cpp turned into customerinfo.cpp)?

Thank you very much for taking the time to look at this
problem and attempt 
to explain it to me. I sincerely appreciate it.

Daniel 


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build