Re: [Boost-build] custom generator problems

Subject: Re: [Boost-build] custom generator problems
From: Vladimir Prus (ghost_at_[hidden])
Date: 2009-03-16 16:37:18

On Monday 16 March 2009 23:21:21 Alexander Sack wrote:
> 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?

If you do know the names of the targets that will be produced, then what
problem are you running into? A custom generator can create as many virtual
targets as it likes, using any names. Or maybe I misunderstand this sentence:

        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?

In general, if a generator's run method is given a.in source and then
creates target a-123.cpp, then a check is made if a-123.cpp is up-to-date.
If it is not, including if it's missing, it's created.

- Volodya