Opened 18 years ago
#17 new defect
multivalued features
| Reported by: | ghost | Owned by: | somebody |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | component1 | Version: | |
| Keywords: | Cc: |
Description
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).
