Skip to content

Conversation

@crueter
Copy link

@crueter crueter commented Dec 30, 2025

This significantly redoes the way shared and static libraries are
handled. Now, it's controlled by two options: SPIRV_TOOLS_BUILD_STATIC
and SPIRV_TOOLS_BUILD_SHARED.

The default configuration (no BUILD_SHARED_LIBS set, options left at
default) is to build shared ONLY if this is the master project, or
static ONLY if this is a subproject (e.g. FetchContent, CPM.cmake). Also
I should note that static-only (i.e. no shared) is now a supported
target, this is done because projects including it as a submodule e.g.
on Android or Windows may prefer this.

Now the shared/static handling:

  • static ON, shared OFF: Only generates .a libraries.
  • static ON, shared ON: Generates .a libraries, but also
    libSPIRV-Tools.so
  • static OFF, shared ON: Only generates .so libraries.

Notable TODOs:

  • SPIRV-Tools-shared.pc seems redundant--how should we handle which one
    to use in the case of distributions that distribute both types (MSYS2
    for instance)?
    • Note: pkgconfig sucks at this and usually just leaves it up to the
      user, so the optimal solution may indeed be doing absolutely
      nothing.
      CMake is unaffected :)
  • use namespaces in the CMake config files pleaaaaase

This is going to change things a good bit for package maintainers, but
cest la vie. It's for the greater good, I promise.

Signed-off-by: crueter [email protected]

This significantly redoes the way shared and static libraries are
handled. Now, it's controlled by two options: `SPIRV_TOOLS_BUILD_STATIC`
and `SPIRV_TOOLS_BUILD_SHARED`.

The default configuration (no `BUILD_SHARED_LIBS` set, options left at
default) is to build shared ONLY if this is the master project, or
static ONLY if this is a subproject (e.g. FetchContent, CPM.cmake). Also
I should note that static-only (i.e. no shared) is now a supported
target, this is done because projects including it as a submodule e.g.
on Android or Windows may prefer this.

Now the shared/static handling:
- static ON, shared OFF: Only generates `.a` libraries.
- static ON, shared ON: Generates `.a` libraries, but also
  `libSPIRV-Tools.so`
- static OFF, shared ON: Only generates `.so` libraries.

Notable TODOs:
- SPIRV-Tools-shared.pc seems redundant--how should we handle which one
  to use in the case of distributions that distribute both types (MSYS2
  for instance)?
  * *Note: pkgconfig sucks at this and usually just leaves it up to the
    user, so the optimal solution may indeed be doing absolutely
    nothing.* CMake is unaffected :)
- use namespaces in the CMake config files pleaaaaase

This is going to change things a good bit for package maintainers, but
cest la vie. It's for the greater good, I promise.

Signed-off-by: crueter <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant