[MacOS] Minimal support/CI pipeline for MacOS ?

[matkara]

It is common to find scientific software/libraries developed/tested on MacOS and then deployed on Linux. As a user, I’m looking forward for a minimal support of MacOS by the Intel sycl/clang compiler. When compiling one of the latest versions of the sycl branch, it fails with the following error

In file included from /Users/matkara/Codes/sycl/llvm/sycl/source/detail/devicelib/fallback-cassert.cpp:9:
/Users/matkara/Codes/sycl/llvm/sycl/source/detail/devicelib/wrapper.h:11:10: fatal error: 'cstddef' file not found
#include <cstddef>
         ^~~~~~~~~
1 error generated.

This error looks similar to the ones encountered in https://github.com/intel/llvm/issues/258

Due to the lack of MacOS build in the testing pipeline of sycl, I don’t know if this error comes from my local setup of the project. Would it be possible to add a minimal support/CI pipeline for MacOS ?

[alexbatashev]

I don’t know if this error comes from my local setup of the project

I'm pretty sure we don't have a buildable macOS in our master. For example, #857 is also os-dependent, and it does not contain any macOS fallback. BTW, if you manage to build the whole thing, it would be great if you submitted a PR.

[pramodk]

Agree with @matkara : many of us develop scientific softwares on MacOS platform. We are curiously looking at OneAPI. Whenever I want to play with samples in free time, requirement of setting some remote development environment on some linux server adds extra barrier.

It would be really helpful to have Mac OS support sooner!

[alexbatashev]

@pramodk how about this. You can use Intel's oneAPI docker containers. You'd loose a bit of performance, but containers are available right now, and it allows you to taste new amazing features of DPC++, like subgroups, which wouldn't be available on macOS due to outdated OpenCL stack. I've had a pretty smooth experience both running vim inside docker, and using vscode remote containers. Would such a workaround meet your needs?

[pramodk]

Thank you @alexbatashev for quick response!

You'd loose a bit of performance, but containers are available right now, and it allows you to taste new amazing features of DPC++, like subgroups

Thanks for pointing out containers! Downloading 5.5 GB image right away :)

Would such a workaround meet your needs?

Containers will definitely help to start with (at least for subset of people) and I am going to play with it. But as a developer, having local dev environment where I can pull specific branch or PR and re-build new LLVM binary is often convenient.

Many of us are curiously trying / experimenting with SYCL in free time. Even we have CPU backend only, it will help to learn/understand programming model. So going forward, having low entry barrier for developers would be really helpful.

[alexbatashev]

Downloading 5.5 GB image right away :)

There's more, than just DPC++ compiler. Other oneAPI components are also included.

But as a developer, having local dev environment where I can pull specific branch or PR and re-build new LLVM binary is often convenient.

If you need an opensource compiler version, you can always build docker containers with linux nightly builds. Those are available on releases tab. Writing a Dockerfile should be straightforward. Alternatively, you can use any CI system, like free tier on GitHub Actions, to build both the compiler and container images. You can see an example workflow for building compiler in our repo. CPU runtime is also available as standalone package on releases page, and can be installed inside containers. This would give you access to latest DPC++ features, and significantly reduce container image size.