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 13:07:03

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

The client_requirements keyword argument came just because it became clear 
that it would be necessary to group all client/usage requirements together.  
I didn't think that it would be necessary to really separate out 
the 'requirements' items.  If you look in the code, you will notice that 
define(...) and include(...) actually instantiate define and include classes.  
Since python has typeid information the project class can know to treat these 
appropriately, as compared to just a source file string for example.

Perhaps there would be a better way to separate out the client requirements 
than I've done above.  We could also certainly have something like:

project('/myLib',
   define('POUND_DEFINE=blah'),
   include('src/'),
   client_requirements(
     include('src/'),
     define('CLIENT_POUND_DEFINE=blar'),
   )
)

where client requirements is also a function/constructor class.

Spencer