Proper implementation for FileNameOption/FileNameOptionStorage - Redmine #642
Archive from user: Teemu Murtola
It should be thought about which features of the old implementation in filenm.c is appropriate for new analysis tools, and those should be implemented in the mentioned classes. It should also be possible to wrap the old code in the new classes, but the interface presented by FileNameOption still has to be thought out carefully. At least the interface should be implemented soon, even if all the internal details are not, to allow development of actual tools without having to worry about the need to change them later to adapt to changes in this interface.
(from redmine: issue id 642, created on 2011-01-08 by gmxdefault, closed on 2014-02-18)
- Relations:
- relates #665 (closed)
- relates #666 (closed)
- Changesets:
- Revision 727418ac by Teemu Murtola on 2011-01-19T16:24:01Z:
Make default option values more flexible.
Added a new method that only provides default values for options that
are set, but for which no value is provided. This makes it possible to
conveniently use file name options like they used to work in the old
tools, namely that '-ox' without a file name would turn on the output
for a certain feature using the default file name. The implementation
now supports the same functionality for all types of options.
IssueID #642
- Revision 762095c2 by Teemu Murtola on 2012-04-18T16:16:14Z:
Split FileNameOption into a separate file.
IssueID #642 (also helps for some alternatives in IssueID #656)
Change-Id: I61b236fcd59963c8ba5f7a49aba2b5197552d316
- Revision 442259a3 by Teemu Murtola on 2012-07-08T05:27:43Z:
Extension completion for FileNameOption.
- Make FileNameOption to complete extensions for input files, like the
old file options did.
- Add descriptions for all file name options to improve the help output.
- Make defaultValueIfSet() really appear in the help output: it worked
only in the case the option value was not stored.
- Adjust the reference for command-line help tests to match the new
output.
Part of #642.
Change-Id: I4a749e3e82a42a6e64e0a78c91120f96a00381b9
- Revision ec1b4a8f by Teemu Murtola on 2012-09-25T01:47:41Z:
Fine-tuning for FileNameOption.
- Change behavior of required options with default values such that the
default value is now used without an error if the option is not
provided. This is how it used to work with file name options. For
most other cases, this combination doesn't make much sense, but
changed it such that it works consistently for all cases.
- Add FileNameOption::defaultBasename() as a more intuitive interface
for providing a default for file name options. The name makes it
clear that no extension is expected, and the option also transparently
treats required/optional arguments without the user needing to
understand the difference between defaultValue() and
defaultValueIfSet().
Closes #642; there is still some things to be improved, but should now
provide about the same features and about the same input options as
the old t_filenm-based system.
Change-Id: Ibcaf0667180e0b24b08604869d855baf23476681
- Revision 39086187 by Teemu Murtola on 2013-10-03T12:07:30Z:
Use filenm.c data for FileNameOption.
Expose the necessary data (through functions) from filenm.c so that
FileNameOption can use it. Removes the need to duplicate the file name
extensions (potentially also other stuff in the future) for the period
that both coexist.
Part of #642.
Change-Id: I0b375da494d6e9c8a0fe6a38d9e1f27078ab9726
- Revision e54b9c33 by Teemu Murtola on 2014-02-09T12:39:40Z:
Make FileNameOption behave more like old filenm parser
If a required file name option is provided without a value, then it is a
no-op. Previously, FileNameOption raised an exception for such usage.
Add a test to cover this case.
Related to #642.
Change-Id: I89d6cc8ee5d5bf2915bb6841317b402ade00b99b