Re: [Boost-build] [python] Python build description

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 
difference.  

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.

Spencer