Subject: Re: [Boost-build] Building a generator binary then using it?
From: Alexander Sack (pisymbol_at_[hidden])
Date: 2008-10-14 12:36:06
On Tue, Oct 14, 2008 at 10:35 AM, Alexander Sack <pisymbol_at_[hidden]> wrote:
> On Mon, Oct 13, 2008 at 5:36 PM, Vladimir Prus
> <vladimir_at_[hidden]> wrote:
>> Alexander Sack wrote:
>>> On Mon, Oct 13, 2008 at 5:18 PM, Alexander Sack <pisymbol_at_[hidden]> wrote:
>>>> On Mon, Oct 13, 2008 at 4:18 PM, Steven Watanabe <watanabesj_at_[hidden]> wrote:
>>>>> Alexander Sack wrote:
>>>>>> I have been slowly getting better at using bjam but I have this
>>>>>> problem. My project has a binary that we build which is then used to
>>>>>> generate C++ files. I have followed the documentation regarding
>>>>>> generators (the VERBATIM example as well as persuing my
>>>>>> $BOOST_ROOT/tools/*.jam files) but I don't know how to get access to
>>>>>> the current build directory to run my generator? Any pointers would
>>>>>> be most appreciated.
>>>>> For a real example you can look at
>>>> Ouch, but this doesn't look like it does it. It looks like it
>>>> searches within BOOST_ROOT or BOOST_BUILD_PATH. The other thing is I
>>>> see a lot of stuff that I'm positive isn't really documented.
>>> Eee gad. No I'm sorry, I looked at it again. Alright this seems to
>>> build the quickbook and then use it. But isn't there something
>>> simpler than this? This is a lot of heavy lifting for such a simple
>> Here's a copy of email describing how to use a built tool inside actions,
>> which is somewhat simpler. The email was a private one, so I can't give
>> an archive URL :-)
>> Also see an example attached.
>> - Volodya
>>> Is there a proper way to specify the path to a generated executable in
>>> an action. In my case tablegen executable is being built at an early
>>> stage of the build process. Later td files are being processed, but the
>>> build system doesn't know where the tablegen exec is located.
>> I don't know the exact setup, but I suspect it's easiest to use a dependency
>> property. For example:
>> feature.feature tblgen : : dependency free ;
>> exe a : a.td : <tblgen>some/dir//tblgen_target ;
>> Then, the action for running tblgen should look like this:
>> toolset.flags tblgen.run COMMAND <tblgen> ;
>> actions unit-test bind COMMAND
>> $(COMMAND:E=tblgen) .......
>> The <tblgen> property can be set as project requirement somewhere, but
>> please make sure that the Jamfile with the tblgen target itself does *not*
>> inherit the tblgen property, as otherwise an infinite building cycle will
>> happen. Presumably, it means tblgen should be set in lib/Jamfile, not
>> I attach a small project that appears to do what you want. Let me know if
>> this works in real setup.
> Alright, my main issue is this is a lot of heavy lifting compared to
> just doing an install rule and then referencing it from some constant
> PATH which certainly works. Is there a reason why the build
> destination is not added to the PATH by default when bjam executes the
> command in a shell?
> In this example the binary is built in a subproject where in my case I
> want to build the tool and use it within the same project (but its the
> same idea trying to bind the COMMAND to a feature which holds the
> My other issue is that my make's have to conditional, i.e. there are
> several variants of the config file which currently is based on a
> project wide feature. How do I add a conditional to a make? Or is
> there a way to check whether a feature is on or off in the current
> build OUTSIDE the property specification? It would seem from the FAQ
> Q1 only a generator really has that ability. Is that correct?
Alright, I came up with this:
local make_target ;
make some.cfg : : @make_some_cfg ;
rule make_some_cfg ( sources * : targets * : properties * )
if <feature>on in $(properties)
make_target = blah ;
Its sort of awkward but it does follow the rule/action paradigm of
bjam language. If anyone has a better idea, I'm all ears?
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