Re: [Boost-build] custom generator problems

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

On Mon, Mar 16, 2009 at 2:20 PM, Vladimir Prus <ghost_at_[hidden]> wrote:
> On Sunday 08 March 2009 08:12:57 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)?
>
> Hmm, how are you planning on doing dependency analysis in this case?
> Say, your tool takes a.in and produces a bunch of cpps. To know if the
> tool should be run, we need to compare checksum of a.in with the checksums
> of the files it will produce -- and running the tool in the first
> place seems wasteful. The tool itself might run in no time, but the .cpp
> files need compilation.
>
> Is there any reasonable way to extract the names from the input file? (Say,
> using a Python script). If so, you can build Boost.Jam with Python support
> and run this code to determine the file names.
>
> If the above is not possible -- is it possible to write a script that runs
> the tool, but in a temporary directory, and reports the list of files
> that are produced? Such a script can be then run using SHELL builtin.
>
> As for path.glob -- no, this won't work -- the names of the targets, in your
> case, must be known before we do initial dependency analysis.

Yes Volodya, I realized that AFTER the fact! :(

I agree its a chicken and egg issue.  I need to tell Boost.Build what
targets (register them) so it can manage them in its dependency
analysis before I can actually create them (as you said).  Well going
down your logic, why can't generators say explicitly what they PLAN to
build and if Boost.Build doesn't see it, then call action?  I.e. what
I was doing is trying to register the names since I DO KNOW them in
advance, is that possible?

For some reason Volodya, register.target was not accepting my lists of
virtual-targets (even if I added CPP CPP H etc. in my definition).

Is that possible?

I ALSO went down your logic of writing a script that runs the tool
then returns the list of files to register but ran into an issue which
Ic an't remember right now...

-aps