Re: [Monotone-devel] overwriteable and negatable options

[Timothy Brownawell]

On 06/13/2010 11:22 AM, Stephen Leake wrote:
> Timothy Brownawell<address@hidden>  writes:

> > These are fun as the default for 'diff' is --with-header and the
> > default for 'automate content_diff' is --without-header.
>
> And I see you have left them separate for now.
>
> I had not anticipated different defaults for different commands.
>
> We could handle that with a default standard hook for
> get_default_command_options. But that would break if people currently
> define that hook but don't add the new code.
>
> We could add other code that is run before the user
> get_default_command_options that provides the same mechanism, and have
> it set these appropriately. That could be useful in the long run, for
> shared options on other commands.

My first reaction is that initializing options to the set state could be 
problematic, but thinking a bit I don't see any actual reason that it 
would be.

I guess we'd have a CMD_PRESET_OPTIONS(name, parent) that takes a 
function body where you can assign opts.foo = ... and can be put near 
the actual CMD() that has the command body?

> > We also have --unknown for add, and a completely separate --no-unknown
> > for inventory. This is also fun due to wanting the default to be
> > different depending on which command is being run.
>
> I think it's ok to have disjoint options with similar names, as long as
> they are used in different commands. 'diff' and 'automate content_diff'
> are very similar commands, so I think we should try to fix that and
> unify those options. I'd be ok with leaving "unknown" and "no-unknown"
> alone. But if we adopt the std_get_default_command_options approach,
> that could used to fix both.

The best part of this is that the option parser will I() if it sees two 
flags with the same name, and we run it with *all* options at first when 
we're figuring out the command name (is "--foo bar baz" running "baz" 
with "--foo=bar", or is it running "bar baz" with "--foo"?).

I suppose the parser could take another flag to indicate that sort of 
preliminary parse, which would make it only I() if the conflicting 
options didn't agree about whether there was an argument (and then make 
it not call the setter functions except for positionals, so you break 
horribly and visibly if you set the flag when you shouldn't).

> I'm getting a link error (Debian, g++ 4.4.3, libboost-all-dev 1.42.0.1):
>
> roster.o: In function `void dump<unsigned int>(unsigned int const&, std::basic_string<char, 
> std::char_traits<char>, std::allocator<char>  >&)':
> /home/Projects/monotone/monotone.options-build/../monotone.options/roster.cc:66: multiple definition of `void 
> dump<unsigned int>(unsigned int const&, std::basic_string<char, std::char_traits<char>, 
> std::allocator<char>  >&)'
> cmd.o:/home/Projects/monotone/monotone.options-build/../monotone.options/cmd.cc:91:
>  first defined here
>
> I don't see what the problem is, nor how to fix it.
>
> I'll try on Win32 MinGW.

I defined a dump<size_t> in cmd.cc, and there's a dump<node_id> in 
roster.cc . node_id is a typedef for u32 and apparently your size_t is 
also 32 bits (mine is 64).

I suppose we need dump specializations for s32, u32, s64, and u64 in 
base.hh and some specified .cc file (cmd.cc?).


--
Timothy

Free public monotone hosting: http://mtn-host.prjek.net