On 06/13/2010 11:22 AM, Stephen Leake wrote:
Timothy Brownawell<tbrow...@prjek.net> 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
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel