Re: [Boost-build] jam/python function calling

Subject: Re: [Boost-build] jam/python function calling
From: Vladimir Prus (ghost_at_[hidden])
Date: 2010-07-14 15:06:29

On Wednesday 14 July 2010 19:09:20 Steven Watanabe wrote:

> AMDG
> 
> Vladimir Prus wrote:
> > It turns out that bjam is a little bit too flexible with types, which causes some pain.
> > Support Jamfile has:
> >
> > 	import feature ;
> > 	feature.feature interpreter : : free incidental ;
> >
> > The matching function in Python is:
> >
> > 	def feature (name, values, attributes = []):
> >
> > The problem is that bjam language has list of strings as the only data
> > type, and Python does not have type declaration. So, given the above,
> > current Python port passes 3 values of type 'list of string' to Python,
> > and when we try to use 'name' as string, things fall apart. Of course,
> > I can hack 'feature' to operate on name[0], but this seems, ehm, nasty.
> >
> > So far, the best approach I came up is:
> >
> > 	@interop([1, 0, 0])
> > 	def feature (name, values, attributes = []):
> >
> > where parameters to the 'interop' decorator mean that first argument
> > passed from bjam should be a list of 1 string and be converted to a string,
> > while two other parameters should be list of strings of any size, and
> > left unchanged. Things are getting nasty for the toolset.flags rule, though:
> >
> > 	rule flags (
> >     	rule-or-module
> >     	variable-name
> >     	condition * :
> >
> > Where the first paramter from bjam should be unpackad into 3 parameters to
> > python code. But presumably, this case can be handled by a custom code.
> >
> > It seems like adding such annotation will be a bit of work. Does anybody
> > have brighter ideas on the syntax, or how to avoid this mess?
> >   
> 
> Python supports tuples in the argument list, so you could use
> 
> def feature((name,), values, attributes = []):
>     print name
>     print values
>     print attributes
> 
>  >>> feature(["interpreter"], [], ["free", "incidental"])
> interpreter
> []
> ['free', 'incidental']
> 
> However, I can't see how to adapt this for flags.
> Also, this forces python code to use the bjam
> signatures, which looks rather awkward.
> 
> I think that something based on attributes is probably
> going to be the best solution.  Maybe something like:
> 
> @jam_signature("rule_or_module variable_name condition * : values * : 
> unchecked ? : hack_hack ?")
> def flags(rule_or_module, variable_name, condition, values, unchecked, 
> hack_hack):

I am starting to think that using exact signature from jam code is the
best approach here. Using magic lists of integers that describe unpacking
appears to be unmaintainable (even though the description has to be
written only once, it better be readable)

Thanks,

--
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build: http://boost.org/boost-build2