Re: [Boost-build] Problem with ambiguity error

From: Daniel Einspanjer (deinspanjer_at_[hidden])
Date: 2006-02-28 15:00:53

"Vladimir Prus" <ghost_at_[hidden]> wrote in message 
news:200602281125.35227.ghost_at_cs.msu.su...
> On Monday 27 February 2006 00:14, Daniel Einspanjer wrote:
>> "Vladimir Prus" <ghost_at_[hidden]> wrote in message
>> news:200602261936.16703.ghost_at_cs.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