[gobolinux-devel] [gobolinux-commits] tools/Scripts/Functions OptionParser

[Hisham Muhammad]

On 11/20/06, Jonas Karlsson <jonka750 at student.liu.se> wrote:
> On Mon, 20 Nov 2006 14:49:26 +0100, Hisham Muhammad
> > $1 works but $2 doesn't, that's the important point.
> >
> What do you mean by $2 doesn't? If $1 works, why not $2? Have I missed
> something?

With Compile foo --flag 2.0, $2 is not 2.0 as the script expects.

> >> > * While I did tell you offlist that I thought the new option parser is
> >> > a great addition, I think  you should have posted this on the -devel
> >> > list before comitting, since it's a big change that affects all
> >> > scripts.
> >>
> >> Oh, I thought you meant to wait until next release was out.
> >> To be honest I think we are too kind with our CVS. Users that track CVS
> >> should know that it might break. If this breaks anything it's very easy
> >> for any user to revert, as it's just to either remove the comment at the
> >> end of Parse_Options or just change the names so that Parse_Options_Old
> >> becomes Parse_Options again. Anyhow, I've tested the most used scripts
> >> and
> >> none break to my knowledge. That's why I need larger testing.
> >
> > I actually run CVS on my production box, and I believe others do too.
> > It's a good way to keep things stable and in check.
> >
> Oh, I wasn't aware of that people use the CVS like that. If that's so,
> maybe releases should be made more often, to ensure that bugfixes are
> straightened out for the "stable" releases, instead of having to rely on
> CVS to have things sane?

You're right, we should make more frequent releases. I think I
expressed myself badly: I run CVS "to keep things stable" not because
it is more stable than the last release, but to keep in check that no
bugs were added since the release for when we prepare the next one.
There's no problem in keeping support for the new option parser
halfway implemented in CVS though (I wouldn't expect changes to all
scripts to be comitted at once), but it's nice to let CVS users know
beforehand when things may break and not be taken by surprise. (Maybe
I was too cautious with this one as it doesn't break anything if
people keep using options the old way -- it should be fully converted
before the next release, though).

> > I know it's not ambiguous, but it "looks ambiguous". I'm not keen on
> > adding features that "should not be used". Like I didn't like your
> > change about letting options be defined without a long or short
> > version - I forced both to be defined every time on purpose, to
> > promote consistency.
> >
> What do you mean by "should not be used"? Does that mean that there should
> be no short options at all, since those should not be used by script
> maintainers?

No, I meant "having options with only long or short options" should
not be used. However:......

> The reason I choose to implement it has two reasons. One is that there's
> no way to come up with good short options for all long options, for
> example look at bug 39 (http://bugs.gobolinux.org/view.php?id=39). If we
> use -V for --no-verify (keeping consistant with capital letters for
> --no-options) what short option should be used for --version?

.....you do have a very good point here. I stand corrected.

> Another reason is that for one specific option (there might come more such
> options) I didn't want to have a short option available, namely for
> --use-contrib for InstallPackage. Having no short option the user has to
> use the long option and then cannot accidently use that option.

Fair.

-- Hisham