Boost logo

Boost-Build :

Subject: Re: [Boost-build] [python] Python build description
From: Spencer E. Olson (olsonse_at_[hidden])
Date: 2010-07-20 12:57:07

On Tuesday 20 July 2010 10:45, 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.

Consider some of the benefits to going strictly with a python front end (and
optional c++/c optimized modules underneath):
1. The language itself it very well documented, widely used, and widely
understood. Gaining traction with users is much easier because of this.

2. By using the python language directly and not using a home-grown parser,
we can leverage that widely known/used language to its fullest. Furthermore,
it also minimizes the amount of maintenance issues with regards to having yet
another language parser (maintenance means: writing syntax documentation,
fixing parser bugs, adding new parser features).

3. For pieces that are deemed to be in need of performance optimization,
these can be reimplemented in c++ or c without the user ever noticing a use

I do think that by using a procedure language, the temptation is to develop
something less declarative, but I certainly believe that we can create
anything that we are willing to program. The test code I sent earlier was
partially to demonstrate that it is possible to write something declarative
in python.


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at