Re: [Monotone-devel] overwriteable and negatable options

[Stephen Leake]

Timothy Brownawell <address@hidden> writes:

> 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.

Ok, good.

> 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?

That makes sense. It would add the body to a global list.

>> 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).

Yes. The MinGW compiler gave a clearer error message.

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

Yes, that fixed it. All tests are passing on Debian and MinGW.

-- 
-- Stephe