Define OTP_VSN/OTP_RELEASE/HAS_CALLBACKS macro

[iilyak]

We define HAS_CALLBACKS feature macro in order to make dialyzer
happy. OTP releases prior to 15 require defining behaviour_info instead
of a callback attribute. New macro could be used to make conditional
compilation as follows:

    -ifdef(HAS_CALLBACKS).
        -callback app() -> atom().
    -else.
        -export([behaviour_info/1]).
        behaviour_info(callbacks) ->
            [
                {app, 0}
            ];
        behaviour_info(_) ->
            undefined.
    -endif.

The same approach could be used to eliminate the cost of erlang:function_exported in couch_crypto.erl.

[kxepal]

Good idea, but patch doesn't applied on current master.

[iilyak]

I'll do rebase.

[iilyak]

rebased

[kxepal]

Thanks! LGFM.

On second thought, we plan to drop R14 support after 2.0 release. And since we don't support R15 even now, do we need this callback workaround in mid/long term?

cc @rnewson

[rnewson]

this could be presented more simply;

OtpVersion = erlang:system_info(compat_rel),
OtpRelease = erlang:system_info(otp_release),
HasCallbacks = OTP_VSN > 14,
Defines = [
    {d, 'OTP_VSN', OtpVersion},
    {d, 'OTP_RELEASE', OtpRelease},
    {d, 'HAS_CALLBACKS', HasCallbacks}
 ],

[kxepal]

I guess @iilyak tried to have more generic solution, but yours simpler and clearer to read. Nice!

[rnewson]

hm, the HAS_CALLBACKS one needs more complexity as you say, it needs to not be defined at all in the 'false' case.

[rnewson]

further hm, how would we use ?OTP_RELEASE in code? We couldn't use a macro conditional on its value in couch_crypto as far as I can see.

[kxepal]

In guards?

md5(Data) when ?OTP_RELEASE >= "17"; ?OTP_RELEASE >= "R15B02" ->
    crypto:hash(md5, Data);
md5(Data) ->
    crypto:md5(Data).

Updated version checks (forgot when crypto deprecation were added).

[rnewson]

In conclusion, I think we need more feature flags (HAS_CRYPTO_HASH) and the version ones aren't useful for conditional compilation.

[kxepal]

Idea with guards will emit another warning about unreachable clause. So it seems the only way is indeed to stay with feature flags.

[iilyak]

I would call it HAS_CRYPTO_V2

[iilyak]

The reason I didn't hardcoded defines as [{d, Key, Value}] is to be able to define some macro from the content of config.erl. But I didn't do a second step to actually use config.erl. I'll update the PR with @rnewson's solution.

[rnewson]

Given we're supporting R16|17|18 and all the features we might test for are always present, do we need to do any of this right now?

[rnewson]

I'd like to to see this simplified, it's a good idea and I'd like to simplify couch_crypto when it lands.

[kxepal]

Good! +1 then when it get simplified.

[iilyak]

Should I add HAS_CRYPTO_HASH or HAS_CRYPTO_V2 (let me know which one) in this PR?

[rnewson]

Since we decided to make R16B03 our minimum, there's no need for HAS_CRYPTO_HASH or HAS_CALLBACKS, we know the features exist.

[iilyak]

Closing since we don't need it at the moment.