id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
17	multivalued features	ghost	somebody	"We should separate the notion of free feature (any value is OK), for multivalued feature (multiple values are OK). Here's what a user writes:

> I use boost build v2 to build my code, and also to run a series of
> tests. These tests require command line arguments, that I provide to
> the executable via these features. Most of these variables have
> predefined values, such as <log_file>/dev/null. But once in a while,
> I'd like to go in there and run a series of tests with e.g.
> <log_file>foo.txt, and being able to do this from the command line
> would help the people running the tests because they wouldn't have to
> play with Jamfiles and such. So yes, ideally, free and multivalued
> would be distinguishable, 

The idea is that for free but non-multivalued feature, you'll be able 
to specify default and override it on the command line. It will be just like 
current <optimization>, except that the list of value is not fixed.

Free multivalued features will behave like current free -- no default allowed, 
and specifying a value anywhere will add another value to existing values (if 
any)."	defect	new	major		component1