Add macOS builds to CI
esabol opened this issue · 9 comments
We probably should be building gearmand on macOS in CI to ensure we don't break anything there.
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?
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
.
It looks like #300 solves
tv_usec
issue. This MacOS CI build runs in the next onelibtest/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
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
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.
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.
At the end we've a succeeded build
Great!