Re: override among command line and config file options

Papp Gyozo (VBuster) wrote:
> Hi there,
> 
>> Papp Gyozo (VBuster) wrote:
>>> The basic logic of my app is the following:
>>>
>>> 1) parse commandline (getoptions_ext)
>>> 2) try to locate a config file (depends on command line options)
>>> 3) parse configfile with no override and no initialize to the same cmdline
>> structure
>>> 4) check required fields
>>>
>>> We stated in the docs for a while that commandline options take precedence
>> over config file. It causes me a little problem at least with group options
>> (these are the old mutual exclusive options, Lorenzo ;)
>>> If an option from a group is given in commandline and in the config file,
>> the generatad parser returns an error: 
>>> "vbscan: 2 options of group ... were given. At most one is required. in
>> configuration file vbscan.ini" (*)
>>> I think what I came to my mind so far would not be not so popular.
>>>
>>> i) move all (or almost all) checking to a dedicated function like require
>> and call this function at the very end of parsing when nothing modifies the
>> option structure. Well actually it may cause compatibility breaks in many
>> applications. However I think it would be great anyway apart from the
>> current situation.
> 
>> are you suggesting something to be implemented in the generated code or 
>> proposing some programming idioms?  I just want to be sure I understand 
>> correctly...
> 
> If we prefer i) then I think something has to be done.
> 
> In my understanding we have a fairly neat interfaces to collect options from different sources: command line, config file. Moreover mode is supported for partioning options, we can add more than one parser to the same program etc. So method for inputs are OK.
> 
> However there is no dedicated function to check only multiple options, groups, dependencies, modes etc in a smooth way so there is no easy way to partition and customize your validation process. The only thing you can check separately is require.
> 
> So what I proposed was to move as many "inter-option" validation routines as possible to a separate interface function which could be called at certain points in the application. I mean "inter-option" that it validates the relationship between two or more option: group, dependencies, modes just to name a few. (I think per option checks, like type, argument needed and its type and so on, may remain where it is now.) Actually multiplicity is a little bit tricky because if the application deals with multiple sources an option can occur more than once in every sources.
> 
> These above were just vague ideas and wonderings. The original problem can be "worked around"
> 

so you suggest to have another function for this, just like the 
check_required function that can be called from the program, right?

cheers
	Lorenzo

-- 
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134     (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com  http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net