Boost logo

Boost-Build :

Subject: Re: [Boost-build] [python] Python build description
From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2010-07-20 13:02:07


On 07/20/2010 12:45 PM, 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.

Even if we only consider a subset of Python ? Python is as much a
multi-paradigm language as C++, and there are ways to express things in
a more declarative way, or in a procedural / imperative way.

I fully agree that the "core" language to declare target dependencies
and rules should be as declarative as possible. But I also see a lot of
value in

a) reusing grammar elements (with their existing semantic !) from a
language as well known as Python
b) make it possible to use other elements from that language, if the
complexities of a given build process require it

As usual, the goal should be to make the normal case trivial, and the
exceptional case possible.

     Stefan

-- 
       ...ich hab' noch einen Koffer in Berlin...

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