[cmake-developers] Custom script invocation from imported target

[Nagy-Egri Máté Ferenc]

Hi!

I am trying to improve the developer experience of SYCL users for both those using triSYCL and ComputeCpp alike. (TL;DR: SYCL is CUDA of OpenCL, triSYCL being a non-conforming playground implementation built atop OpenMP, while ComputeCpp is the first (and only) conforming GPU-accelerated implementation.) Although they are two wildly different implementations, it would come in handy to mix the two, having Debug builds rely on triSYCL (for the usual breakpoint-style debugging inside kernels) and Release builds using ComputeCpp, as well as generally allowing any implementation to be detected and used (much like find_package(MPI) can find MPI-CH, MS-MPI as well as OpenMPI).

My problem is that even if I have the nicest imported target set up in a FindModule.cmake script with components pointing to the various implementations (my initial take on the problem), there is no way for me to call the ComputeCpp compiler just by linking to an imported library target. This was the reason CUDA up until CMake 3.9 used add_cuda_executable() function and is the same reason why ComputeCpp uses the add_sycl_to_target() function.

If I would like to raise the bar to the level of CUDA in terms of UX, I’d need to patch CMake to being SYCL-aware. It would be much simpler however if imported targets had the ability to invoke user-defined scripts (defined in the FindModule.cmake script) that is invoked with the supplied parameters. Something like:

# FindLibrary.cmake
set(important „something important”)

function(add_stuff_to_target TARGET target
                             IMPORTANT_VAR var)
  …
endfunction(add_stuff_to_target)

add_library(Vendor::Library INTERFACE IMPORTED)

# NOTE: TARGET <name> is always added as a param to SCRIPT when linked to.
# NOTE 2: SCRIPT is only valid for IMPORTED libraries.
set_target_properties(Vendor::Library PROPERTIES SCRIPT add_stuff_to_target
                                                 SCRIPT_PARAMS IMPORTANT_VAR ${important})

# CMakeLists.txt
find_package(Vendor REQUIRED COMPONENTS Library)

add_executable(MyProg main.cpp)

target_link_libraries(MyProg PRIVATE Vendor::Library)

This (or some similar way) libraries need not necessarily have to patch CMake in order to implement features such as:
- Qt MOC-ing files
- CUDA ptx compilation
- HLSL/GLSL compilation (this could be an object library that is linked to a CUSTOM_SCRIPT enhanced imported library
- XAML compiler invocation
- SYCL force include file generation
- I’m sure there are many more similar use cases

The function would always receive the target name, from where just about everything can be queried, things originating from the FindModule.cmake script (counterparts to vars like CMAKE_AUTOMOC) could be passed in as well.



To sum it up: do you see value in lowering the bar to this level in adding significant facilities to CMake independently of CMake itself? This way, these facilities would be much more agile if updates to them need not wait for a new CMake version.

Cheers,
Máté
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170920/c674cc4e/attachment.html>