WIP: improve version automation based on CMake project version

[bashbaug]

This PR has some ideas I've been considering to improve version automation. The ideal goal is to derive all versioning from the CMake project version so no other versioning has to be set "manually".

For now I haven't changed any versions, so the Linux so still has version 1.2 and soversion 1 and the Windows DLL still has version 3.0.3. It would be a one line change to the CMake file to build a so with version 1.2.3 instead, though, see related discussion in PR #75.

I did add a trace message to print the ICD loader revision for now, to provide a way to know the ICD loader revision on both Windows and Linux.

I'll keep this WIP until we figure out if this is something we want to do or if we want to make additional changes at the same time.

[Kerilk]

Great idea. Should we add something akin to:
clGetICDLoaderInfoOCLICD
https://github.com/OCL-dev/ocl-icd/blob/1165deedb2ae741cd76e60986f7c2cb5023059d9/ocl_icd_loader.c#L901
So the loader can be introspected (name, vendor, version, ...)?

[bashbaug]

Should we add something akin to...

This is an interesting idea. I can see how something like clGetICDLoaderInfoOCLICD could be useful. There are a couple of other "ICD loader extensions" I've been considering as well.

Good reminder too - if we do start versioning the Khronos ICD loader more precisely do we need to coordinate versioning with the ocl-icd loader, since they both build a libOpenCL.so?

[Kerilk]

From the introspection mechanism, right now, ocl-icd returns:

CL_ICDL_OCL_VERSION: "OpenCL 3.0"
CL_ICDL_VERSION: "2.3.1"
CL_ICDL_NAME: "OpenCL ICD Loader"
CL_ICDL_VENDOR: "OCL Icd free software"

We could have the official Khronos Loader return:

CL_ICDL_OCL_VERSION: "OpenCL 3.0"
CL_ICDL_VERSION: "3.0.3"
CL_ICDL_NAME: "OpenCL ICD Loader"
CL_ICDL_VENDOR: "Khronos" or "The Khronos Group Inc."

We could also devise a feature/extension parameter name query to know if the loader supports layers, system layers, device ordering etc...

For library versioning ocl-icd uses the same symbol versioning as we do here, but the library version is 1.0.0:

libOpenCL.so -> libOpenCL.so.1.0.0
libOpenCL.so.1 -> libOpenCL.so.1.0.0
libOpenCL.so.1.0.0

Built with libtool using -version-info 1:0:0 which translate into: -Wl,-soname -Wl,libOpenCL.so.1, which is the same somane we are using in the official loader: -Wl,-soname,libOpenCL.so.1. The only difference is that we are naming our library files differently:

libOpenCL.so -> libOpenCL.so.1
libOpenCL.so.1 -> libOpenCL.so.1.2
libOpenCL.so.1.2

But I am unsure this difference has any consequence in practice. I am not an expert on shared library versioning issues, but I don't see a reason to diverge from what we've been doing for now, I think the symbol versioning map file is fine. I think the query mechanism should allow tools (e.g. clinfo) and application to introspect the loader to know what version it is, and what features it implements.

[bashbaug]

The only difference is that we are naming our library files differently...

This is my concern, though I'm not sure if it's a real concern or if I'm just being paranoid.

One way to interpret the different library naming / versioning is that the Khronos ICD loader is always newer than the ocl-icd loader because the Khronos ICD loader has version 1.2 and the ocl-icd loader has version 1.0.0. This obviously is not always the case, though. Is this something to worry about?

I guess we wouldn't be making the problem any worse if we added a "patch" version to the Khronos ICD loader so it had version 1.2.X vs. 1.2. We're also lucky that we currently have different versioning (1.2 vs. 1.0) so we won't have a Khronos ICD loader and an ocl-icd with the same file name (the symlinks are a different story, but that's OK).

[Kerilk]

On Debian based systems icd loaders are all named in the same manner and mutually exclusive:
https://packages.debian.org/search?searchon=contents&keywords=libopenCL.so&mode=filename&suite=stable&arch=any
So I don't think name conflicts are a real issue. The fact that the nvidia one does not provide versioned symbols is a bigger problem though. Installing ocl-icd and the official loader side by side would require using update-alternatives approaches, but it shouldn't be impossible.
In an HPC context this is irrelevant anyway because applications built with one or the other are already compatible with the other one, so switching loader is as easy as switching environment modules (with the quirk that the set of environment variables supported are not the same).

On rpm based distributions, they all seem to be called libOpenCL.so.1
https://rpmfind.net/linux/rpm2html/search.php?query=libOpenCL.so*&submit=Search+...&system=&arch=

I would need to talk to distribution managers/packagers, to understand if changing numbers, or packaging the official one as is would cause issues. I am out of my depth here.