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 10:35:43

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?

-aps