Re: [help-gengetopt] flag setting issues with override

[Papp Gyozo (VBuster)]

> First, out of curiosity, why are you using flag options instead of 
> options without arguments?  Would you be able to simulate the same 

To be frank, dunno. :) Now  I've realized from CVS that I used flags from the 
beginning (~ gengetop 2.11). I think now that flags seemed to the obvious 
choice for simple on/off options. I don't remember quite well but probably 
there might be some little glitches with simple options that time.

Just to be precise you are suggesting such changes like below?

option  "flag" f
        "real flag"
        flag off
        hidden

option  "flag" f
        "mimic flag"
        off
        hidden

> behavior of flag options?  This is just my curiosity, in order to be 
> able to understand whether we're able to get rid off flag options someday :)

I think this change is really worth considering and should be targeted now for 
an _exact_ future release. (gengetopt 3.0?) I mean the next releases may emit 
warning messages on flag options, then successive releases refuse to accept 
them by default only if a specific option is set. (-compat-flag). Finally all 
the hassle should be left out.


> This is the best solution, since adding a new parameter is backward 
> compatible, so how about override_flags?  If set to 0, this would 
> simulate your
> 
> if (field_given && *field_given && ( !override || arg_type == ARG_FLAG ))
> 
> i.e.,
> 
> if (field_given && *field_given && ( !override || (arg_type == ARG_FLAG 
> && !override_flag)))
> 
> what do you think?

It could work.
 
> > In a long run, I would prefer to change flag option generation as to gcc's
> options.
> > I mean to generate to separate options for setting and reseting flags:
> >   -flag    # to enable (switch on) the `flag'
> >   -no-flag # to disable (switch off) the `flag'
> > 
> 
> I was asked to add such functionality and I'd like to work on this, but 
> these would not be real flag options: it would be options without name 
> with an automatic generation of the '-no-' corresponding version.

It would be nice. Go for it :)
I proposed that the old flag semantics could be "recycled" this way. 

> > I hope this way we could avoid several problems and misunderstandings
> around flag options. Unfortunately it breaks compatibility.
> 
> why would it break backward compatibility?  I mean the solution with 
> additional param should not break backward compatibility (if set by 
> default to 1).

BC break will occur only if you drop the old flag behaviour and introduce this 
new -f/-no pairs under the same name This was what I suggested. Introducing a 
new param in the generator may handle BC.