An SDK starter template & guide

[Whotakesmyname]

This great SDK is exactly what I was imagining of when I saw the (reasonably) cumbersome C API in the OpenCL guide. However, it is still a little confusing for a new user to figure out where to start. Should I:

1. use this whole repo as another dependency, or should I
2. tailor it to be a codebase as my own repo?

Even the draft guide I found in the issue #3 did not utilize the SDK utility. For now I am pursing the second way.

I learnt some CMake but using it still heavily relies on Google. The add_sample macro is great but only for the samples. This repo provides splendid examples with an elegant project structure, but if it can include a boilerplate to start with, that would be even better. Also, a practical "Get Start With" guide will bring in much more usefulness.

Thank you for your work. It is really appreciated. Personally, I am especially interested in the GL&CL interop part, which attracted me here.

[MathiasMagnus]

Hi,

thanks for taking an interest in the SDK. It's good to know people find it and that they think it's useful.

As for your first question: SDKs aren't designed to be dependencies, not in their entirety at least. This has bothered me as well, that using vendor SDKs, it wasn't clear how to "consume the SDK". In CMake-land the preferred way is to consume dependencies as pre-built entities, although making deps part of your build has varying degrees of support too. Long story short, if you're looking to build stuff outside the SDK, the best trampoline sources are those used in CI where we check if an SDK installation is actually consumable by downstream. A typical and minimal CMake file looks like this, as a source file, you can copy the associated platform enum cpp. Some of the support around getting started and CMake support in particular can be found in the OpenCL-Guide.

A fairly decent introduction to CMake from my quill can be found here but if you intend on using it professionally, I highly advise spending a few bucks on Craig Scott's Professional CMake: a Practical Guide.

One typical tedious task around using OpenCL with CMake is how to handle resources, such as kernel code in a way that the executable always finds it. The SDK does take care of this inside the add_sample macro you mentioned and it's commented nicely why it's done that way so that both the build and install trees have the kernel code next to the executable. I have a few other techniques with various pros/cons detailed here.

Hope this answers your questions.

[Whotakesmyname]

Your detailed reply is really appreciated. I am especially interested in the GL&CL interoperation, so I spent 1 day having managed to tailor the whole repo for my use. If you are interested, it's here. Suggestions are welcomed.

In the process, I almost read through your cmake files in each directory and did some dirty works, mostly about removing dependency to some sample-related variables and defines. Because I want to reuse your SFML+SDK utility, which is only turned on when some variables like BUILD_OPENGL_SAMPLE are set, I felt it not friendly for us to reuse this part. But after all, your cmake files are one of those most well-written ones, so I managed to understand it mostly and make it work for me.

Before any greedy request like making it more user-friendly and reusable, one simple question is whether the CPP part depends on the C part utility? Because I seemed to see a dependency here. I assume libraries like cargs are not needed for my C++ code (TCLAP is used I see), but so far I cannot drop it without getting a build failure.

Thank you for your guide about those CMake manuals! I will read them later. One pain is that CMake always confuses me by mixing deprecated features with modern ones. Different (modern) guides have different sets of "modern" practices. Hope it can abandon what it thinks as "deprecated" like Python3 and move on with more orthogonal features.