From: David Abrahams (dave_at_[hidden])
Date: 2004-12-30 16:03:41
Vladimir Prus wrote:
> On Wednesday 29 December 2004 23:02, David Abrahams wrote:
>> The introduction of a special named parameter interface for declaring
>> projects and the introduction of an "attribute" concept seem to me to be
>> entirely gratuitous, since the things one has to declare for a project
>> have so much in common with the "common syntax" for declaring main targets
>> Projects Main targets
>> ======== ============
>> project id (name) name
>> requirements requirements
>> source location
>> build directory
>> default-build default-build
>> usage requirements
>> If you just represent source location and build directory as features
>> that can be given values in the project's requirements or default-build,
>> you have now unified the two declaration syntaxes.
> This is true. The problem now is that
> 1. Project cannot use positional parameters
> 2. Target cannot use named parameters
> What do you think about allowing named parameters for targets?
I'm trying to make the system easier to explain and I'm not convinced
this complication is neccessary.
> At least when I
> need to specify usage requirements on a target I'm always confused.
I suggest two possibilities:
1. We wait 'till other users complain
2. If we need to do something eventually, perhaps <usage><feature>value
in the requirements area would help. Likewise <default><feature>value.
> So, we'll be able to write:
> project foo : <include>bar ;
> exe main : main.cpp : requirements <include>biz ;
*if* we're going to do something like this I want a special syntax that
makes it clear it's a keyword and not something else, e.g.
I want to leave room for BBv1 property processing function feature
should we want it later
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
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