Boost logo

Boost-Build :

Subject: Re: [Boost-build] [python] Python build description
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2010-07-20 12:50:44


Rene Rivera wrote:

> On 7/20/2010 11:12 AM, Vladimir Prus wrote:
>> On Wednesday 14 July 2010 22:50:01 Spencer E. Olson wrote:
>>
>>> project('/myLib',
>>> define('POUND_DEFINE=blah'),
>>> include('src/'),
>>> client_requirements=[
>>> include('src/'),
>>> define('CLIENT_POUND_DEFINE=blar'),
>>> ]
>>> );
>>>
>>> library('library',
>>> 'src/myLib/func.cpp',
>>> define('OTHER_POUND_DEFINE=hahaha'),
>>> 'src/myLib/other.cpp',
>>> );
>>
>> Spencer,
>>
>> this looks pretty nice. I have one design question though --
>> what is the guideline when to use function (e.g. 'define') and when to
>> use keyword arguments (like 'client_requirements')? How can this be
>> explained to users, so that there's no confusion?
>
> Haven't chimed in about this subject.. But I'm not fond of using Python
> as the description language. Sorry, but it's just not suited for the
> job. I'd rather keep something like the Jam syntax, but integrated with
> Python. I.e. writing the parser in Python would be fine. But it's just
> that I think Python is the wrong tool for writing declarations.

Just to clarify where the current effort is going -- I don't plan to
kill the use of Jam language, however, it appears that limitations on
what you can do in Jam language will be somewhat strict. In essense,
it will be possible to define targets, action/rule makes (to use with
make/notfile) and maybe relatively simple conditional logic. As soon
as you need to write code that needs to touch classes (like custom
generators, or code that creates virtual targets), you need to write
this code in Python. I am working, right now, on a mechanism to
have both build.py and build.jam in the same directory, so that
the latter can use functions defined in the former, but I suspect
for many users, it will be more convenient to write everything in
one language and in one file.

- Volodya


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