Re: [Boost-build] custom generator problems

Subject: Re: [Boost-build] custom generator problems
From: Alexander Sack (pisymbol_at_[hidden])
Date: 2009-03-16 13:32:30

On Mon, Mar 16, 2009 at 12:45 PM, Michael Caisse
<boost_at_[hidden]> wrote:
> Alexander Sack wrote:
>>
>> One more note, I *think* one could glob over the target directory
>> where your generated files are and then register new
>> virtual-file-targets so they become managed files??  This is very
>> similar to the PYTHON Example in the doc on generators (what I did for
>> my protobuf example).  I'm going to have look at this later today.
>>
>> Btw do you REALLY not know the name of them at all or could you
>> actually right rules like obj <targetname> : <type that generates it>
>> style lines then have your binary depend on them potentially?  (I'm
>> just asking)
>>
>
> Thank you for the hints. I reviewed and played with this some more
> last night and hopefully will get a chance to devote more time
> this week.
>
> I actually don't know the names in advance. The code generator takes
> an xml (xmi) file as input that describes a UML model. The output of
> the generator is a bunch of files based on the UML model. I wrote
> the code generator so I could determine what the file names are
> going to be based on looking at the xml file, but I think this
> is no different than glob'n over the target directory at the end.
>
> If you have any other insight or direction I should look I would
> be grateful. I started looking at all of the build/*.jam files
> last night. Something that I have been trying to avoid up to now.

Yea I started to play with it myself last week until I got real real
busy at work (I also found due to the awesome economy I'm not going to
Boostcon which is a royal bummer).  I was trying to understand how to
use the virtual-target.jam classes to create new targets to register
with Boost.Build.  This is key I believe.  From my understanding of
looking at bjam/Boost.Build source, generators use the virtual-target
class to register new filetype/actions so Boost.Build knows how to
maintain it.  The issue I had was chicken & egg.  I needed to know in
advance what was the name of the targets generated so I could register
them otherwise I had to call the action early on so I could glob over
the resultant files and then register them.

I plan to look at this some more in my spare time...I'm trying to
collect common examples in order to update the doc since this area of
Boost.Build is very mysterious and jam source is at least for me,
difficult to follow (determine the type of a call or object is like
playing Where's Waldo sometimes - IF I HAD nickel for everytime I see
glob, GLOB, GLOB_ glob_ ..., its a little out of control).

In the meantime you can always hand do things with a @notfile rule
etc. (I know I know, not what you want...).

-aps