Add macOS builds to CI

[esabol]

We probably should be building gearmand on macOS in CI to ensure we don't break anything there.

[p-alik]

As mentioned here macOS build fails for variety of reasons yet.

[esabol]

I'm seeing this in my OS X High Sierra build (which compiled and tested OK, just a lot of warnings):

libgearman-server/connection.cc:722:29: warning: implicit conversion loses integer precision: 'long' to
      '__darwin_suseconds_t' (aka 'int') [-Wshorten-64-to-32]
        timeout_tv.tv_usec= (long)((milliseconds % 1000) * 1000);

At least some versions of macOS, Apple apparently used int instead of long for tv_usec in struct timeval. The solution is to use suseconds_t for the type instead. I think that works on Linux as well?

[p-alik]

It looks like #300 solves tv_usec issue. This MacOS CI build runs in the next one libtest/server_container.cc:52:61: error: 'ptr_fun<int, int>' is deprecated.

[esabol]

It looks like #300 solves tv_usec issue. This MacOS CI build runs in the next one libtest/server_container.cc:52:61: error: 'ptr_fun<int, int>' is deprecated.

I think we want to use the following instead:

    s.erase(std::find_if(s.rbegin(), s.rend(), [](int ch) {
        return !std::isspace(ch);
    }).base(), s.end());

What do you think?

References:
https://stackoverflow.com/questions/44973435/stdptr-fun-replacement-for-c17
https://stackoverflow.com/questions/40575929/how-to-replace-stdptr-fun-with-stdfunction-and-stdref
https://stackoverflow.com/questions/216823/whats-the-best-way-to-trim-stdstring/216883

[esabol]

I think we need to keep both versions? Use #if __cplusplus > 201402L for C++17 or >= 201103L for C++11?

Reference:
https://stackoverflow.com/questions/38456127/what-is-the-value-of-cplusplus-for-c17

[p-alik]

    s.erase(std::find_if(s.rbegin(), s.rend(), [](int ch) {
        return !std::isspace(ch);
    }).base(), s.end());

What do you think?

Your proposal is fine for g++ (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 and the style matches std::isspace reference implementation.

Unfortunately my presumption to solve BOOST_WORKAROUND is only partly true. This CI build hits the issue on other parts of code.

[esabol]

Unfortunately my presumption to solve BOOST_WORKAROUND is only partly true. This CI build hits the issue on other parts of code.

Did you add the following?

#ifndef __clang_major__
#define __clang_major___WORKAROUND_GUARD 1
#else
#define __clang_major___WORKAROUND_GUARD 0
#endif

If so, where did you add it? You probably need to add it to every file that exhibits this boost problem. Or some common header file included by it.

None of this happens if you boostrap on Linux and then compile it on macOS. I'm not clear why that is.

[p-alik]

If so, where did you add it?

see 4c03a24

At the end we've a succeeded build

[esabol]

At the end we've a succeeded build

Great!