spirv-tools: build static library as well

[crueter]

Not sure why this was off. It's particularly useful for certain CI applications where SPIRV-Tools is better off being linked statically

---

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>?
• Is your test running fine brew test <formula>?
• Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

• AI was used to generate or assist with generating this PR. Please specify below how you used AI to help you, and what steps you have taken to manually verify the changes.

---

[GunniBusch]

I think as per brews policy, it is preferred to have shared libs. https://docs.brew.sh/Acceptable-Formulae#shared-vs-static-libraries. And if there are static libs required formulae might ship both. (ignore this if you actually meant to have shared AND static)

[crueter]

Yeah I want to have shared and static. Their handling is kind of goofed up right now, which might cause the build failure; I do have a pending PR there to fix it KhronosGroup/SPIRV-Tools#6481 but it stalled because I'm lazy and also haven't called for reviews yet. Will investigate more when I next get access to my ARM linux machine

[daeho-ro]

I don't see any changes from your PR, there isn't easy way to install dynamic and static at the same time and then what is the difference between as-is and to-be?

[GunniBusch]

so the cmake file says this

# Library build setting definitions:
#
# * SPIRV_TOOLS_BUILD_STATIC - ON or OFF - Defaults to ON.
#   If enabled the following targets will be created:
#     ${SPIRV_TOOLS}-static - STATIC library.
#                             Has full public symbol visibility.
#     ${SPIRV_TOOLS}-shared - SHARED library.
#                             Has default-hidden symbol visibility.
#     ${SPIRV_TOOLS}        - will alias to one of above, based on BUILD_SHARED_LIBS.
#   If disabled the following targets will be created:
#     ${SPIRV_TOOLS}        - either STATIC or SHARED based on SPIRV_TOOLS_LIBRARY_TYPE.
#                             Has full public symbol visibility.
#     ${SPIRV_TOOLS}-shared - SHARED library.
#                             Has default-hidden symbol visibility.
#
# * SPIRV_TOOLS_LIBRARY_TYPE - SHARED or STATIC.
#   Specifies the library type used for building SPIRV-Tools libraries.
#   Defaults to SHARED when BUILD_SHARED_LIBS=1, otherwise STATIC.
#
# * SPIRV_TOOLS_FULL_VISIBILITY - "${SPIRV_TOOLS}-static" or "${SPIRV_TOOLS}"
#   Evaluates to the SPIRV_TOOLS target library name that has no hidden symbols.
#   This is used by internal targets for accessing symbols that are non-public.
#   Note this target provides no API stability guarantees.
#
# Ideally, all of these will go away - see https://github.com/KhronosGroup/SPIRV-Tools/issues/3909.

I would lie if I say I am not confused

[crueter]

Yeah, it might need to wait on my PR. MSYS2 does some weird stuff just to get it to work:

https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-spirv-tools/PKGBUILD

I'll see if I can fast-track that PR to prevent this nonsense.

[crueter]

However, it is possible that for the time being this will have to build twice. Fixing the shared/static library definitions at the SPIRV-Tools level is a considerably larger task that is well outside the scope of that PR.