> 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
option "flag" f
> 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 ))
> 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
> > 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.