Boost logo

Boost-Build :

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

"Vladimir Prus" <ghost_at_[hidden]> wrote in message
> On Monday 27 February 2006 00:14, Daniel Einspanjer wrote:
>> "Vladimir Prus" <ghost_at_[hidden]> wrote in message
> 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:
> 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*
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

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

> 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

> 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.


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at