build: support find_package basisu via CMake + CMake improvements

[aminya]

This adds needed CMake commands to make basisu usable via find_package(basisu CONFIG), which is the preferred method when using basisu in another project.

This is how the installation directory would look like

I added an option that allows for disabling the building of the examples, which can be optionally enabled. I added the code for forwarding the BASISID CMake definitions to the targets if defined externally.

Finally, I fixed an issue with stripping when using Multi-config generators with LLVM.

Here's how you can test this:

cmake -S . -B ./build/ -G "Ninja Multi-Config" -DEXAMPLES=OFF
cmake --build ./build/ --config Release
cmake --install ./build/ --config Release --prefix ./install

[grawlinson]

Would be great if this got merged! Any updates?

[dg0yt]

Subscribing. I have review comments, but it doesn't make sense until a merge is planned.

[Pandapip1]

Seems like #408 has probably superseded this PR.

[dg0yt]

I also found #408 after my comment. But this is what I found in the vcpkg port. I read the lack of official response in this PR as a red flag.

[dg0yt]

Edit: I didn't see #408, I saw several CMake related PRs.
https://github.com/BinomialLLC/basis_universal/pulls?q=is%3Apr+is%3Aopen+cmake++in%3Atitle

[Pandapip1]

Yea, I also ended up making my own independent CMake improvements before seeing any of the N PRs

Pandapip1@e2f294d

[aminya]

Given that I opened this PR a year ago, the probably of the maintainers responding is low.

[sehurlburt]

Hey all,

I noticed the active interest in CMake and given our recent commit wanted to clarify that we generally can’t take CMake changes quickly unless deemed absolutely critical. We considered 408 because the KTX2 standard that we contributed to expressed it was critical for that project, but even then we didn’t take all changes at this time due to the domino effects CMake can often have that make it hard to test.

We’re keeping these open cause they’re not bad ideas and as we do major releases that naturally involve intense rounds of testing, we try to loop in some “nice to have” PRs we see. In the meantime, you are of course welcome to use a fork or edit your copy of the repo to have these improvements. If you do feel like the changes are critical to the health of an important codebase, do let us know why and you can also e-mail me at stephanie@binomial.info to explain your use case further.

Really appreciate the ideas and suggestions around builds!

[Pandapip1]

Sure thing. Note that https://github.com/NixOS/nixpkgs will be applying this patch in the meantime. Whoops wrong PR, we'll be applying #409

[dg0yt]

This PR reflects patching in vcpkg. Both basisu and ktx are packaged in vcpkg. Installation, devendored dependencies and exported CMake config are essential for a good experience with package managers.
And some aspects could be applied immediately, incrementally. Like making examples opt-out. Or defining the namespaced target name for downstream usage.

[aminya]

I kept this PR backwards compatible (e.g. examples are still enabled by default), so it should not affect the current users. If you consider this, it would be great. I find other PRs lacking or having changes that's out of the scope of the backwards compatible CMake improvements. Also, the fact the Microsoft vcpkg users have been benefiting from this without issues is good reason to accept this. @sehurlburt

[sehurlburt]

I think the idea of allowing examples to be disabled is a very useful one, so thank you for mentioning that! The next big release is currently scheduled for January 2026, so we’ll do our best.

[richgel999]

I kept this PR backwards compatible (e.g. examples are still enabled by default), so it should not affect the current users. If you consider this, it would be great. I find other PRs lacking or having changes that's out of the scope of the backwards compatible CMake improvements. Also, the fact the Microsoft vcpkg users have been benefiting from this without issues is good reason to accept this

Thank you - this is great. We're preparing a very big Jan/Feb 2026 release. I'll merge as much of this as I can along with PR 409 (another package/cmake related PR). I'll definitely make the examples (more are coming) optional.

[richgel999]

I've merged in the EXAMPLES change to make them optional. Also the MSVC .manifest file is now in the cmake build. I'll merge more before the Jan/Feb. 2026 release.