[PATCH] tests: add compatibility layer

[Mikhail]

On 18:48 03-Jan 2017 Tomi Ollila wrote:
>>
>>  # Finally, after everything configured, inform the user how to continue.
>> diff --git a/test/README b/test/README
>> index 104a120e..8376616f 100644
>> --- a/test/README
>> +++ b/test/README
>> @@ -33,6 +33,12 @@ chosen directory to your PATH before running the tests.
>>
>>  e.g. env PATH=/opt/gnu/bin:$PATH make test
>>
>> +For FreeBSD you will need to install coreutils, which provides GNU
>> +versions of basic utils like 'date' or 'wc'. Also you will need to
>> +install latest gdb from ports or packages and provide path to it in
>> +NOTMUCH_GDB variable before executing the tests, native FreeBSD gdb will
>> +not work.
>
>I think this is a bit too strong statement; one should not *need* to
>install such a bloaty beast as a GNU coreutils to use instead of nice
>native utils system is shipped with; IMO this should mention that
>installing coreutils (in a way that these g-prefixed commands appear
>in PATH!) may improve the success of test run... or something.

GNU utils is what developers use and what majority of users are using.
Tests, in my view, have been created to test functionality of notmuch,
and if user want to be sure that notmuch is working as expected - he
should use the tools developers were using. There is not much difference
anyway - mostly spacing in 'wc' or column number in 'base64', or '-i'
handling in 'sed', or 'date' flags.

Improving success rate is not a goal, goal - 100% test passing, as on
Linux. To get closer to 100% - install coreutils, if it isn't 100% -
there is a problem - it has to be investigated.

If you don't want 100% passage - there is a difference in our goals and
we are talking about different things.

>> +date () { gdate "$@"; }
>> +base64 () { gbase64 "$@"; }
>> +gdb () { $NOTMUCH_GDB "$@"; }
>> +wc () { gwc "$@"; }
>> +sed () { gsed "$@"; }
>> +sha256sum () { gsha256sum "$@"; }
>
>The above is currently problematic when one does not install GNU coreutils;
>tests will fail more when e.g. `gwc` does not exist but `wc` does. When I
>tested with this patch a few days ago, test failure count increased from
>~70 to ~140. That was the quickly written mkwrp() for...

>I use my freebsd KVM virtual machine for e.g. portability testing; things
>that work on freebsd (in addition to linux) have more chance to work on
>netbsd, openbsd, macos, solaris, openindiana. With the above applied
>verbatim I would always need to remember to dump the "compatibility file"
>before running tests...
>
>To fix the above, one could use (possibly better written) mkwrap()
>implementation, or do all of those by hand: e.g.
>
>if command -v gdate >/dev/null; then date () { gdate "$@"; }; fi
>if command -v gbase64 >/dev/null; then base64 () { gbase64 "$@"; }; fi
>...
>
>the gdb wrapper could be dumped completely and have the following in
>test-lib-common.sh:
>
>: ${NOTMUCH_GDB:-gdb}
>
>and then replace all (the few) gdb in code with $NOTMUCH_GDB (did not use
>quotes like "$NOTMUCH_GDB" so that one can hack args there.
>
>but if the gdb function were there, then the following might work:
>
>gdb () { command ${NOTMUCH_GDB:-gdb} "$@"; }

My only concern is a simplicity, if installing coreutils and "alias'ing"
native 'wc' to 'gwc' solves the problem - why to create more entities?
In real world, if you have gwc - you have gbase64, I can't imagine any
exceptions.