View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0013091 | CMake | CCMake | public | 2012-03-31 19:10 | 2012-09-03 16:00 | ||||
Reporter | Christoph Anton Mitterer | ||||||||
Assigned To | Brad King | ||||||||
Priority | normal | Severity | feature | Reproducibility | always | ||||
Status | closed | Resolution | suspended | ||||||
Platform | OS | OS Version | |||||||
Product Version | |||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0013091: add enum like options | ||||||||
Description | Hi. I know this is a duplicate of bugs 0007313 and 0001527 and the (not longer existing?) #39. I also know there is no real way of implementing enums, given the way cmake works. But can't the following be done: If for any variable "foo" a variable like "foo_ALLOWED_VALUES" exist, then and UIs (like ccmake, etc.) are allowed to interpret this variable in order to restrict the possible user inputs (yes I know it will still be possible via manual editing and via the command line to set any value). For the syntax of "foo_ALLOWED_VALUES" I'd recommend a extensible format e.g.: "<type>:<type-dependent-data>" Perhaps starting with the two types: enum regexp 1) enum could be something like this: enum:value[|value]* Where value is a allowed value. 2) regexp: could be something like this: regexp:<regexp-type>:<expression> With regexp-type being for example POSIX_BRE for POSIX Basic Regular Expressions, or POSIX_ERE for POSIX Extended Regular Expressions. Maybe later one could add PCRE. expression would be the regular expression that must be matched for a value to be allowed. Why (1)? (2) would not allow for UIs to make choices (e.g. drop down lists), at least not easily. Chris. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Relationships | |
Relationships |
Notes | |
(0029023) David Cole (manager) 2012-03-31 21:14 |
This is already quite possible. Please see http://www.kitware.com/blog/home/post/82 [^] for details. |
(0029024) Christoph Anton Mitterer (reporter) 2012-03-31 21:54 |
Great! So I could basically re-design the option command with set and a property that allows on and off, right? So let me re-dedicate this bug to the following tasks: 1) The above should really be better documented, than in a "private" blog. It's actually in the manpage, but I guess it wouldn't harm if there are: - a reference at the set command - a reference at the option command - FAQ and / or wiki entries 2) It seems to not work yet in ccmake, an honestly I guess most developers stick to the console than to fancy GUI toys. 3) I still believe that the idea with the regular expressions could be worth implementing, of course via the property mechanism. Shall I open a new bug for this? |
(0029096) Brad King (manager) 2012-04-09 09:03 |
Issues 0013083, 0013089, 0013090, 0013091, 0013092, 0013109, and 0013111 are all interesting suggestions but the issue tracker is not a good place to discuss them. The user list is a better place for discussion because it may attract interest from others, and in particular from potential contributors. Others may also suggest alternative solutions. |
(0030846) David Cole (manager) 2012-09-03 16:00 |
Closing resolved issues that have not been updated in more than 4 months. |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2012-03-31 19:10 | Christoph Anton Mitterer | New Issue | |
2012-03-31 21:14 | David Cole | Note Added: 0029023 | |
2012-03-31 21:54 | Christoph Anton Mitterer | Note Added: 0029024 | |
2012-04-09 09:03 | Brad King | Note Added: 0029096 | |
2012-04-09 09:03 | Brad King | Status | new => resolved |
2012-04-09 09:03 | Brad King | Resolution | open => suspended |
2012-04-09 09:03 | Brad King | Assigned To | => Brad King |
2012-09-03 16:00 | David Cole | Note Added: 0030846 | |
2012-09-03 16:00 | David Cole | Status | resolved => closed |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |