Re: [Boost-build] Building a generator binary then using it?

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:
>>>>> AMDG
>>>>>
>>>>> 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
>>>>> http://svn.boost.org/trac/boost/browser/trunk/tools/build/v2/tools/quickbook.jam
>>>>
>>>> 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
>>> task.
>>
>> 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
>> Jamroot.
>>
>> 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
> PATH.
>
> 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 ;
}

actions make_some_cfg
{
   my_binary $(make_target)
}

etc. etc.

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?

-aps