[shaderc] Use build type to build targets

[JackBoosY]

Currently, shaderc has generated dynamic libraries, static libraries and static libraries containing all dependent binaries at the same time.
This PR will:

• Determine whether to generate a dynamic library or a static library according to BUILD_SHARED_LIBS.
• Disable generating static libraries containing all dependent binaries.

Partly solved #15452.
Fixes #16122.

[JackBoosY]

Waiting for merge #16138.

[ras0219-msft]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ras0219-msft]

This LGTM

[jmoguillansky-gpsw]

Hi @JackBoosY I updated vcpkg to the latest version. It seems that only static shaderc was built.
How do I build the shared lib?
Am I supposed to set BUILD_SHARED_LIBS environment variable or something?

[jmoguillansky-gpsw]

Seems that this PR disables shaderc shared library build?

#Note: glslang and spir tools doesn't export symbol and need to be build as static lib for cmake to work
vcpkg_check_linkage(ONLY_STATIC_LIBRARY)

This part doesn't make sense. If glslang and spir-tools require static shaderc then they can link against the static shaderc, that doesn't mean that shaderc doesn't support shared library build?

[JackBoosY]

@jmoguillansky-gpsw For building shared, use command ./vcpkg install shaderc.
You should use the right triplet to build it.

[jmoguillansky-gpsw]

@jmoguillansky-gpsw For building shared, use command ./vcpkg install shaderc.
You should use the right triplet to build it.

Hi @JackBoosY ,
Yes I tried that: vcpkg install shaderc:x64-windows, but it still only built the static lib?

[JackBoosY]

@jmoguillansky-gpsw Ops, sorry, I forgot we force it to build as a static library.
I will investigate later.

[ras0219-msft]

The issue is not that glslang and spir-tools require static shaderc -- rather, the problem is that glslang and spir-tools can only be built statically, which means building a shared library for shaderc is extremely suspect (it will contain a duplicate copy of the glslang/spir-tools code along with the main application binary as well as any other consumers). Shaderc consumes glslang, not the other way around.

Therefore, until glslang and spir-tools can be built dynamically, we do not want to build shaderc dynamically.

[jmoguillansky-gpsw]

Shaderc upstream supports shared lib build, and its shipped as part of vulkan sdk. There's no issue with shaderc , the tool just decides to use the static lib, thats all

[jmoguillansky-gpsw]

I think there's a broader discussion with regards to vcpkg architecture. Each module doesn't know how it's used, only what it can build. Some executables may choose to always use static lib, some shared lib, etc. From my perspective the vcpkg architecture should accomodate these cases.
One option:
The module should build all supported configurations (static, shared, etc).
Vcpkg integrate install can have a param of default lib type (e.g. shared or static) the same way that a linker (ld on linux) has a param to specify default lib type.

[jmoguillansky-gpsw]

Regarding vcpkg integrate install:
Maybe one option to consider is:
let the user navigate to a project and type something like "vcpkg integrate <module name>" and then vcpkg will integrate the module into the project.
This gives the user convenience, but perhaps safer than making all libs globally available for all msvc projects,etc.

[JackBoosY]

glslang and spir-tools only depend on the static library, not dynamic.