property_list.hpp:63:1: error: call to unavailable member function 'value': introduced in macOS 10.14

[jeffhammond]

Recent builds of the PRK with triSYCL are broken on MacOS in Travis CI because the implementation appears to be assuming 10.14 (Mojave).

From https://travis-ci.org/ParRes/Kernels/jobs/509999834:

make -C Cxx11 p2p-hyperplane-sycl stencil-sycl transpose-sycl nstream-sycl
/usr/local/opt/llvm/bin/clang++ -pthread -std=c++17 -DPRKVERSION="2.16" -DUSE_SYCL -I/Users/travis/build/ParRes/Kernels/PRK-deps/triSYCL/include -DUSE_SYCL -DUSE_2D_INDEXING=0 -DUSE_RANGES_TS -I/Users/travis/build/ParRes/Kernels/PRK-deps/range-v3/include -DUSE_RANGES p2p-hyperplane-sycl.cc -o p2p-hyperplane-sycl
In file included from p2p-hyperplane-sycl.cc:62:
In file included from /Users/travis/build/ParRes/Kernels/PRK-deps/triSYCL/include/CL/sycl.hpp:40:
In file included from /Users/travis/build/ParRes/Kernels/PRK-deps/triSYCL/include/CL/sycl/buffer.hpp:27:
In file included from /Users/travis/build/ParRes/Kernels/PRK-deps/triSYCL/include/CL/sycl/queue.hpp:30:
/Users/travis/build/ParRes/Kernels/PRK-deps/triSYCL/include/CL/sycl/property_list.hpp:63:1: error: call to unavailable member function 'value': introduced in macOS 10.14
TRISYCL_PROPERTY_HAS_GET(queue, enable_profiling)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/travis/build/ParRes/Kernels/PRK-deps/triSYCL/include/CL/sycl/property_list.hpp:60:22: note: expanded from macro 'TRISYCL_PROPERTY_HAS_GET'
    return prop_name.value();                                           \
           ~~~~~~~~~~^~~~~
/usr/local/opt/llvm/bin/../include/c++/v1/optional:938:33: note: candidate function has been explicitly made unavailable
    constexpr value_type const& value() const&
                                ^
/usr/local/opt/llvm/bin/../include/c++/v1/optional:947:27: note: candidate function not viable: 'this' argument has type 'const std::optional<property::queue::enable_profiling>', but method is not marked const
    constexpr value_type& value() &
                          ^
/usr/local/opt/llvm/bin/../include/c++/v1/optional:956:28: note: candidate function not viable: 'this' argument has type 'const std::optional<property::queue::enable_profiling>', but method is not marked const
    constexpr value_type&& value() &&
                           ^
/usr/local/opt/llvm/bin/../include/c++/v1/optional:965:34: note: candidate function not viable: no known conversion from 'const optional<...>' to 'const optional<...>' for object argument
    constexpr value_type const&& value() const&&
                                 ^
1 error generated.

Since triSYCL is tested using Docker, which I don't know how to use (and lack the time to learn, so anyone suggesting it is wasting their time), I've setup a more direct testing environment that mirrors the PRK setup:

https://github.com/jeffhammond/trisycl-macos-travis

What's rather unfortunate about this is that triSYCL is the best/only way to test SYCL on MacOS, because CodePlay ComputeCpp doesn't support it.

[keryell]

I have started a few weeks ago trying to compile on MacOS. I have found it very difficult just to have a decent modern Unix environment working on MacOS, such as modern Clang/LLVM with OpenMP... I am happily accepting any suggestion on this. I started with HomeBrew. A complication factor: I barely have any access to a Mac. :-) But we plan to buy a Mac mini in the lab soon for this...

Otherwise, https://github.com/jeffhammond/trisycl-macos-travis you are suggesting does not seem to have any real content for now.

[jeffhammond]

I have no problem compiling with the standard toolchain on Mojave. It's just the older MacOS versions that are broken right now. However, I think it's important to do continuous integration testing on MacOS going forwards, so I am glad that you are buying a Mac mini.

jrhammon-mac02:Cxx11 jrhammon$ clang++ -std=c++17 -pthread -DPRKVERSION="2.16" -DUSE_SYCL -I./triSYCL/include -DUSE_SYCL -DUSE_2D_INDEXING=0 -DUSE_BOOST_IRANGE -DUSE_BOOST -I/usr/local/Cellar/boost/1.65.1/include -DUSE_RANGES nstream-sycl.cc -o nstream-sycl

jrhammon-mac02:Cxx11 jrhammon$ clang++ -v
Apple LLVM version 10.0.1 (clang-1001.0.46.3)
Target: x86_64-apple-darwin18.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

You are right that my testing repo is empty. I have been in meetings all week and haven't had time to finish.

[keryell]

I have no problem compiling with the standard toolchain on Mojave. It's just the older MacOS versions that are broken right now.

Ah, I think I misunderstood your point. It works with the last version of MacOS, but not with Travis CI because they use an obsolete version of MacOS. Well, triSYCL is about modern C++ and not about clearing the technical debt of some specific companies... ;-)

Otherwise, I am surprised to see make -C Cxx11 above, because triSYCL is not that old... But at the end it looks like using -std=c++17 anyway. Curious. :-)

For the Mac mini side, it is about some internal triSYCL branches using C++20 for Xilinx ACAP Versal we want to demo also on some Mac laptops but that we cannot open-source yet because it would expose some architectural details...

[jeffhammond]

If you want to declare all but the latest MacOS version obsolete, so be it, but Apple supports latest and latest-1 so some people maybe on the latter.

Cxx11 is the name of the subdirectory where the PRK implementations using modern C++ exist. I decided not to rename the subdirectory every time I use a feature from later ISO C++ standards. I compile with C++14 or C++17 flags now, whichever is required to make it work.