CMake integration for ComputeCpp

[mcopik]

We have been very happy to use CMake scripts for building SYCL apps with ComputeCpp in our project. It simplifies integration with existing codebases significantly, but our experience suggests that the current approach is not perfect. I don't know the rationale behind this design but so far I have seen two ways of integrating CMake in open-source projects:

• CMake config file - in a third-party project user is required to pass only one install directory where CMake config file can be located; variables are read and used later to find headers, libraries, compilation and linking flags etc.
• CMake find_package script

The first option is obviously not applicable in this scenario because the interesting part is code for adding targets for building SYCL code. The second option is convenient as long as the script is freely available, either already distributed with CMake itself or shipped with the package itself - then integration is built on top of one user-defined installation directory. In the case of ComputeCpp, the location of the script is completely independent of ComputeCpp's current location. Therefore, a user of HPX has to either modify CMAKE_MODULE_PATH on the command line or pass two variables, one used to extend module path internally and one used to locate ComputeCpp. It's a very non-standard solution and quite inconvenient.

We could have included FindComputeCpp in our project and distributed it with HPX but it is not a preferred option - we would have to keep watching your repo to not miss updates and solve possible licensing issues, which may not be a problem, but we are always cautious when adding a third-party code to HPX which is not on Boost license.

Is there a specific reason why CMake scripts are distributed with SDK? We believe that it's perfectly reasonable to include it in ComputeCpp installation package and it would allow SYCL-based projects to configure build with just one user-defined path.

[DuncanMcBain]

Hi Marcin, we understand what you're asking for, however, we separated the CMake from the ComputeCpp releases because having it as part of the SDK allows us to make changes independently of the main package releases. These may be infrequent which would limit how often we could update FindComputeCpp.cmake, which we'd rather avoid.

In future we plan to have an installer of sorts which would automatically clone the SDK for you, to keep things more in sync. From what I can tell, the boost licence is a modified apache licence, so there shouldn't be any conflicts there particularly. At the moment I suppose you could clone the SDK inside the ComputeCpp install directory (provided you don't install in a root location, which isn't always possible - I install to $HOME).

[MathiasMagnus]

On a related note, but arriving at it from a totally different angle:

@DuncanMcBain, what are your thoughts on having upstream CMake support for ComputeCpp?

Do you think that the parameters to the device compiler are stable enough for such an effort to be worthwhile? I believe the extra compilation step resembles that of CUDA very much, as well as the AUTOMOC machinery of Qt. I believe taking a look at both, one could copy-paste together something similar to make it simple enough to just creating a target property, much like AUTOMOC does.

[mmha]

Hey @MathiasMagnus ,

I have been thinking about that for a while now and started an experiment a couple of months ago here. It uses the fairly undocumented way of adding a new language to CMake. There are smaller bugs here and there (and there was a limitation in our compiler driver until very recently that prevented me from adding device-only compiler flags) and I still need to add separate compilation instead of using -sycl-driver exclusively, but I am using this for my own code.

AUTOMOC is something deeply hardcoded in CMake, but CUDA is almost exclusively CMake script.

Feel free to make any contributions, we can also take this to the Kitware Gitlab or their mailing list and ask if there is any interest in upstreaming this. There are things that would need to be added to CMake such as support for certain properties. For example. the list of available language standards is hardcoded in C++, so we can't just set CMAKE_SYCL_STANDARD to 1.2.1 and expect it to be checked without upstream support.

[bmanga]

+1 for moving the cmake files into ComputeCpp from me.
The installation without these files is not very practical, and it seems from the commit history that those files are not updated that often.

[DuncanMcBain]

The latest release of ComputeCpp ships the CMake as a find_package compatible file.