Fine tune SYCL RTC's `resource.cpp` generation

[aelovikov-intel]

llvm/sycl-jit/jit-compiler/CMakeLists.txt

Lines 26 to 30 in c10603b

	add_custom_command(
	OUTPUT ${SYCL_JIT_RESOURCE_CPP}
	COMMAND ${Python3_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/utils/generate.py --toolchain-dir ${CMAKE_BINARY_DIR} --output ${SYCL_JIT_RESOURCE_CPP} --prefix ${SYCL_JIT_VIRTUAL_TOOLCHAIN_ROOT}
	DEPENDS
	${SYCL_JIT_RESOURCE_DEPS}

that only depends on

llvm/sycl-jit/jit-compiler/CMakeLists.txt

Lines 12 to 24 in c10603b

	set(SYCL_JIT_RESOURCE_DEPS
	sycl-headers # include/sycl
	clang # lib/clang/N/include
	${CMAKE_CURRENT_SOURCE_DIR}/utils/generate.py)
	if ("libclc" IN_LIST LLVM_ENABLE_PROJECTS)
	# Somehow just "libclc" doesn't build "remangled-*" (and maybe whatever else).
	list(APPEND SYCL_JIT_RESOURCE_DEPS libclc libspirv-builtins) # lib/clc/*.bc
	endif()
	if ("libdevice" IN_LIST LLVM_ENABLE_PROJECTS)
	list(APPEND SYCL_JIT_RESOURCE_DEPS libsycldevice) # lib/*.bc
	endif()

However, generate.py just blindly captures everything in build/lib/clang/**:

llvm/sycl-jit/jit-compiler/utils/generate.py

Lines 49 to 57 in c10603b

	def process_dir(dir):
	for root, _, files in os.walk(dir):
	for file in files:
	file_path = os.path.join(root, file)
	process_file(file_path)
	process_dir(os.path.join(args.toolchain_dir, "include/"))
	process_dir(os.path.join(args.toolchain_dir, "lib/clang/"))
	process_dir(os.path.join(args.toolchain_dir, "lib/clc/"))

which causes two types of issues:

• We distribute more than we necessarily need/want
• Flaky build errors. The way output files are created is often such that in-progress writes happen to a temporary file that is later renamed once all the writes finish. If that file is created by a project/runtime we don't depend on, then resource.cpp might capture that temp file that won't be available by the time resource.cpp is being built, failing at the corresponding #embed directive.

[cperkinsintel]

I think we can get rid of the race simply by tightening up the DEPS to something more specific than "all of clang".

But how can I test to be sure?