Hi,
You are correct that as it stands it is challenging to add custom
linking / compilation steps in CMake for moc
The challenge with these approaches is that you
1. The unfortunate truth is that a cmake configure time script lacks
the required information. Numerous things such as the location of
libraries or config type need to be delayed to generation or execution
time.
2. Things such as CUDA separable compilation, and I believe MOC, and
HSL/GSL also need to invoke the original COMPILATION and LINK steps
but now with additional libraries or objects that need to be added.
3. My thinking is you really wanting better ability to add custom
languages to CMake. Have you explored having SYCL as a custom
language?
4. With CMake 3.9 CUDA ptx compilation is natively supported using
OBJECT libraries and the CUDA_PTX_COMPILATION property
On Wed, Sep 20, 2017 at 8:12 AM, Nagy-Egri Máté Ferenc via
cmake-developers <cmake-developers@cmake.org> wrote:
> 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é
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
