Re: [Boost-build] custom generator problems

Subject: Re: [Boost-build] custom generator problems
From: Alexander Sack (pisymbol_at_[hidden])
Date: 2009-03-09 14:57:25

On Sun, Mar 8, 2009 at 1:55 AM, Michael Caisse
<boost_at_[hidden]> wrote:
> Michael Caisse wrote:
>>
>> I am trying to create a custom generator for a code generator.
>> The code generator takes a single description file in and
>> produces several CPP and HPP files.
>>
>> The produced filenames are not known before hand; however, I have them
>> generated into a known directory. I was hoping to path.glob the code
>> generated files but I am starting to think
>> that this isn't going to work.
>>
>> Before I devote much more time to this approach is this even possible?
>> Can I create rules that determine targets only after some
>> action is performed (the code generator runs and the directory is glob'd)?
>>
>> Thank you for your consideration.
>>
>> michael
>>
>>
> I know it is rude to reply to your own posts, but ....
>
> After searching the archives, I think Alexander Sack has been asking
> questions about a similar task. While I am looking forward to Alexander's
> session at BoostCon, I sure would like to solve this before May.
>
> Ultimately I need to chain generators to convert multiple
> types:
>
>  zargo -> xmi -> room -> cpp/h
>
>
> Using standard generators I can do this; however, the last
> step produces several cpp/h files. I wanted to make a custom
> generator that would glob the files that were generated but
> I get the impression that Alexander has discovered a method
> for his use that is different. However, I cannot seem to find a post with
> the solution. Alexander? Are you sharing?

Sorry I've been so busy outside of boost stuff for the past week in my
day job its been tough.  Yea it was going to be in my examples and I
think the above is actually another good thing I haven't thought about
(chaining generators and multiple targets from a single source).

I had two issues with generators which I think are very popular and
Vladimir helped me a lot (in fact perhaps he should give the talk, I
only suggested the talk after I went through converting a very large
build to use bjam as a POC and found all of these non documented or
half documented issues, but I think the talk might be a good idea no
matter what).

I had two scenarios, one I solved, one I'm in the process of
solving....these were the scenarios:

- I had a tool that took an XML file and generated several CPP and H
that needed to be in the build:

foobar gen.xml -> random CPP and HEADER files that need to be used to
build some other LIB

Unfortunately, at the time I worked around it but I suppose I should
go back and solve it with a full fledge generator.  The issue is the
non-boost build generated these files and then copied them over to the
right spots to be included in the build of another library in another
directory (within the overall project hierarchy).  So at the time I
wrote a simple notfile rule with a corresponding rule/action to
emulate that behavior (and sure enough it worked).

I know, I know, I know, not that graceful....but since I've been
called out on it, I suppose I should go back and solve it.

- I had a tool that took a customized INPUT text file (.proto) and
produced a CPP and a H file but unfortunately input.ext did not equate
to input.cc and input.h etc.

foo.proto->foo.pb.cc and foo.pb.h -> use these files to build a
library and or binary

So here I had to register new file-targets as well as an action using
the virtual-target class which allowed me to register what I wanted
Boost.Build to do when foo.proto is listed as a dependency.

-aps