From: Kirill Lapshin (kir_at_[hidden])
Date: 2007-03-13 05:36:34
John, I think core boost.build developers are very busy trying to kick
1.34.0 out of the door, hence the slow response rate.
I suppose you are trying to put together ANTLR support, right? I for one
would like to get proper ANTLR support in boost.build, but never had
enough time/enthusiasm to learn boost.build internals and build proper
solution. However I would be happy to help out with testing etc.
At the moment I have quick and dirty solution -- basically I modeled
ANTLR support after whale toolset, which works reasonably well in the
scope of single project, provided you can enforce some rules on file
names, e.g. foo.g should produce foo_lexer.cpp/hpp and
foo_parser.cpp/hpp. I realize that it is not a proper solution, but may
work for you as a stop gap measure.
John Reid wrote:
> John Reid wrote:
>> Suppose I have a tool that compiles files of type .g into .cpp .hpp and
>> .txt files. The names of these generated files can not be determined
>> from the filename of the source .g file.
>> I can register the .g type and create a rule and an action to run the
>> tool. I am having problems using custom generators to tell boost.build
>> which files the tool will generate.
>> I've looked at the documentation:
>> and I figured the quickest and easiest way to do this is to define
>> features that are set on each .g source file and then inspect them in
>> the generated-targets rule of the custom generator. Does this sound
>> Given the above I've struggled to work out how to return appropriate
>> values from the custom generator rule. The documentation does not seem
>> to cover this at all. Could someone provide me with example code to
>> extract a filename from a feature and build a suitable return value for
>> the generated-targets rule from it?
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk