Broken static builds on Windows

[MathiasMagnus]

As previously discussed with some of the vendors, static builds on Windows haven't been working for some time. There's a lengthy disclaimer on why one wouldn't want to do this, but DLL handling is tedious enough that in controlled/development environments one may get away with it.

Some of the changes around ICD loading on Windows (summoning @jenatali) neatly reorganized things to headers/sources, but without the overhead of creating export headers and decorating functions when building a static library, one symbol ends up missing and the loader will not link. (Symbol export happens on a case-by-case basis based on usage. With multiple TUs, the compiler may not see the use of a symbol rendering it absent from the object file of the TU.)

Once the CI/CD changes make it into the repo, #226, I'd propose adding this commit on top as a hotfix. It turns the Windows-specific parts of the loader into header-only, bringing function definitions closer to the location of use. This allows omission of generating an export header.

[jenatali]

Please, please, do not encourage static builds of the loader. Apps which use a static loader will then start embedding search locations for drivers, which seriously limits the operating system's ability to evolve over time. If it were up to me, the option would be removed.

Statically linking a loader only makes sense when the app is including a specific ICD that it wants to use, but in that case, you don't want a loader, you just want a dispatcher. Perhaps look at what LunarG has done with the Vulkan loader for direct driver loading? That allows the loader to be used just as a dispatcher, bypassing driver discovery completely.

[MathiasMagnus]

There is a lengthy disclaimer in the CMake scripts describing precisely the same pitfalls you did too. It is stated that it's "if you know what you're doing" territory and "thou shall not ship" programs this way.

[Kerilk]

I think we should develop and advertise solutions like this one:
KhronosGroup/OpenCL-Headers#169
That could serve the same purpose, while being more future proof.
@bashbaug has made similar proposals as well in the past.

I could revisit the above and fully generate it now that header generation is not an issue.