External dependancy for sycl targets

[dbabokin]

Would be nice to have an ability to explicitly specify dependency for SYCL file via DEPENDS parameter of add_sycl_to_target() in CMake builds.

[MathiasMagnus]

What is the use case? (Just wondering.) We had a similar issue with Qt, that a source file depended on generated UI header and the SYCL compiler was invoked too early, and at one time needed the addition of:

set(device_compiler_includes "-I${CMAKE_CURRENT_BINARY_DIR}")
get_target_property(targetSources ${SDK_BUILD_IR_TARGET} SOURCES)
foreach(targetSource ${targetSources})
  list(APPEND ir_dependencies ${targetSource})
endforeach()

to FindComputeCpp.cmake but AUTOUIC solved this issue. There are still patches needed to get a Qt app to compile, and I do intend on upstreaming my changes, but if there's something out there I've not thought of, there might be a common way to solve both our problems.

[DuncanMcBain]

Hi @dbabokin, I've been going through some of our older issues and I was wondering what sort of use-case you have for this? For ComputeCpp, if you depend on the SYCL header, then you need to depend on the TU that generated it, so this should be handled. In the other direction, if you want the SYCL header to depend on some other header or code, it should propagate the dependencies in the right direction if the original target depends on that header (or other entity).

[dbabokin]

My use case was depending on external generated header file included by SYCL .cpp file. So I needed SYCL target to depend on another target, which was generating the header. That's not a very frequent case, but in this case DEPENDS is what you need to handle it right.

[DuncanMcBain]

Ah, I understand. This is a good idea - I'll see if we can make progress on it. I imagine it shouldn't be too hard.

Thanks!