How many different kinds of command-line options

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

How many different kinds of command-line options

David Abrahams
...do we have in Boost.Build?

Seems to me we have

  bjam -jamoption -sVARIABLE=setting --bboption --bboption=value feature=value
                                                ^^^^^^^^^^^^^^^^
                                                Not sure we're using
                                                this one

Somehow this just seems too confusing.  Am I missing something?

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: How many different kinds of command-line options

Vladimir Prus
On Friday 10 February 2006 21:11, David Abrahams wrote:

> ...do we have in Boost.Build?
>
> Seems to me we have
>
>   bjam -jamoption -sVARIABLE=setting --bboption --bboption=value
> feature=value ^^^^^^^^^^^^^^^^
>                                                 Not sure we're using
>                                                 this one
>
> Somehow this just seems too confusing.  Am I missing something?

I think that would be confusing to have it all, but:

  1. The -sVARIABLE=setting is not used in V2, at least I never used it.
  2. --bboption=value is used only in help system.
 
So, the commonly used options are

   -jamoption --bboption feature=value

and -jamoption are used mostly for -d* options. Maybe, we can add --options
for all -joption, i.e, if we have

   -n

we can add

   --dry-run

with the same effect. Do you think that will improve things?

- Volodya

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: How many different kinds of command-line options

David Abrahams
Vladimir Prus <[hidden email]> writes:

> On Friday 10 February 2006 21:11, David Abrahams wrote:
>> ...do we have in Boost.Build?
>>
>> Seems to me we have
>>
>>   bjam -jamoption -sVARIABLE=setting --bboption --bboption=value
>> feature=value ^^^^^^^^^^^^^^^^
>>                                                 Not sure we're using
>>                                                 this one
>>
>> Somehow this just seems too confusing.  Am I missing something?
>
> I think that would be confusing to have it all, but:
>
>   1. The -sVARIABLE=setting is not used in V2, at least I never used
>   it.

I know, but v1 isn't gone yet.  Even after it is, users will have it
in their brains from v1, and it's on various mirrors around the web.
Probably the Wiki also.

>   2. --bboption=value is used only in help system.

And that somehow makes it less of a factor? The help system is one of
the most exposed parts of BB.

I've certainly used this syntax in BBv1 for other things, e.g.

     "--debugger=devenv /debugexe"

that I would like to see replicated in v2.

> So, the commonly used options are
>
>    -jamoption --bboption feature=value

You don't think the help system will be commonly used?

> and -jamoption are used mostly for -d* options. Maybe, we can add --options
> for all -joption, i.e, if we have
>
>    -n
>
> we can add
>
>    --dry-run
>
> with the same effect. Do you think that will improve things?

Maybe.  Do you think new users will really not write

        --feature=value

by mistake?  I think *I've* done that, as a matter of fact.  It's
especially bad because we don't, IIUC, detect unused --options.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: How many different kinds of command-line options

Vladimir Prus
On Monday 13 February 2006 16:32, David Abrahams wrote:

> Vladimir Prus <[hidden email]> writes:
> > On Friday 10 February 2006 21:11, David Abrahams wrote:
> >> ...do we have in Boost.Build?
> >>
> >> Seems to me we have
> >>
> >>   bjam -jamoption -sVARIABLE=setting --bboption --bboption=value
> >> feature=value ^^^^^^^^^^^^^^^^
> >>                                                 Not sure we're using
> >>                                                 this one
> >>
> >> Somehow this just seems too confusing.  Am I missing something?
> >
> > I think that would be confusing to have it all, but:
> >
> >   1. The -sVARIABLE=setting is not used in V2, at least I never used
> >   it.
>
> I know, but v1 isn't gone yet.  Even after it is, users will have it
> in their brains from v1, and it's on various mirrors around the web.
> Probably the Wiki also.

But we can't do much about this. I think we've all agreed long time ago that
-s is not the best interface.

> >   2. --bboption=value is used only in help system.
>
> And that somehow makes it less of a factor? The help system is one of
> the most exposed parts of BB.

Well, probably, I did not use it recently though.

<aside>
Maybe we need to increase the role of --help option by consistently trying to
redirect users to it when applicable.
</aside>

> I've certainly used this syntax in BBv1 for other things, e.g.
>
>      "--debugger=devenv /debugexe"
>
> that I would like to see replicated in v2.

Ok, that seems reasonable.

>
> > So, the commonly used options are
> >
> >    -jamoption --bboption feature=value
>
> You don't think the help system will be commonly used?
>
> > and -jamoption are used mostly for -d* options. Maybe, we can add
> > --options for all -joption, i.e, if we have
> >
> >    -n
> >
> > we can add
> >
> >    --dry-run
> >
> > with the same effect. Do you think that will improve things?
>
> Maybe.  Do you think new users will really not write
>
>         --feature=value
>
> by mistake?  I think *I've* done that, as a matter of fact.  It's
> especially bad because we don't, IIUC, detect unused --options.

Detecting unused options will be right approach. As for "--feature=value"
syntax, I'm not sure regular options are features are exactly the same and
should not use different syntax.

- Volodya

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: How many different kinds of command-line options

David Abrahams
Vladimir Prus <[hidden email]> writes:

>> > 1. The -sVARIABLE=setting is not used in V2, at least I never used
>> >   it.
>>
>> I know, but v1 isn't gone yet.  Even after it is, users will have it
>> in their brains from v1, and it's on various mirrors around the web.
>> Probably the Wiki also.
>
> But we can't do much about this. I think we've all agreed long time
> ago that -s is not the best interface.

I know.  My point is just that the problem will be a serious one; we
should be thinking about ways to further simplify the v2 interface to
compensate.

>> >   2. --bboption=value is used only in help system.
>>
>> And that somehow makes it less of a factor? The help system is one
>> of the most exposed parts of BB.
>
> Well, probably, I did not use it recently though.

Well, *you're* not a newbie!

> <aside>
> Maybe we need to increase the role of --help option by consistently
> trying to
> redirect users to it when applicable.
> </aside>

Probably a good idea.

>> > So, the commonly used options are
>> >
>> >    -jamoption --bboption feature=value
>>
>> You don't think the help system will be commonly used?
>>
>> > and -jamoption are used mostly for -d* options. Maybe, we can add
>> > --options for all -joption, i.e, if we have
>> >
>> >    -n
>> >
>> > we can add
>> >
>> >    --dry-run
>> >
>> > with the same effect. Do you think that will improve things?
>>
>> Maybe.  Do you think new users will really not write
>>
>>         --feature=value
>>
>> by mistake?  I think *I've* done that, as a matter of fact.  It's
>> especially bad because we don't, IIUC, detect unused --options.
>
> Detecting unused options will be right approach. As for
> "--feature=value" syntax, I'm not sure regular options are features
> are exactly the same and should not use different syntax.

I'm not sure either, but I think we ought to be aware of the
possibility and try to head off as many problems as possible.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build