Feature: Allow building `nk_shared` as a static archive (for runtime dispatch under static linkage)

[kyusic]

Use case

Some downstream projects need both:

1. Static library linkage — to avoid shipping libnumkong.so and managing RPATH on the deploy side.
2. Runtime SIMD dispatch — because the build machine and target machines have different CPUs (e.g. a single CI build deployed to a fleet of servers with mixed AVX-512 / AVX2 / older SSE features).

Any consumer that compiles with NK_DYNAMIC_DISPATCH=1 needs the compiled c/numkong.c + c/dispatch_*.c objects available at link time, since the headers in that mode emit only extern declarations for the dispatch entry points (nk_find_kernel_punned, nk_dot_*, etc.). A static archive containing those objects would satisfy the link without forcing distribution of a shared library.

Current limitation

The if (NK_BUILD_SHARED) block in CMakeLists.txt hardcodes the library type:

add_library(nk_shared SHARED ${NK_SOURCES})

So NK_BUILD_SHARED=ON always produces a .so/.dll. There is no in-tree way to produce a libnumkong.a containing the dispatch sources — users that need "static archive + dispatch" must patch CMakeLists.txt.

This surfaces most visibly in the vcpkg port, which degrades to header-only when VCPKG_LIBRARY_LINKAGE=static:

if(BUILD_SHARED)
    vcpkg_cmake_config_fixup(PACKAGE_NAME unofficial-numkong)
    ...
else()
    # numkong is a header-only library when the library linkage is static.
    file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug")
endif()

That's fine for compile-time-dispatch consumers (NK_DYNAMIC_DISPATCH=0, the default), but breaks any consumer that needs runtime dispatch under static linkage.

[ashvardanian]

Hi @kyusic! Makes sense, would you like to open a PR?