KTX read-only library

[atteneder]

Added an additional library target ktx_read for users who only want to read KTX files. Especially useful if binary size is a concern.

• Had to restructure the CMake config a bit to avoid redundancies.
• Added an option to force creation of static libraries. I needed this to create a .bundle library for Unity macOS.

At the moment this additional lib is built by default. We could make options to en-/disable it (also for the default lib).

Thanks!

[MarkCallow]

I'd prefer if the additional library was only built when an option is set to build the read-only library. However it should always be built by CI so CI should set the option.

[atteneder]

The tools ktx2check and ktxinfo should also work if linking against ktx_read (instead of ktx). I tried and the tests did not break.

@MarkCallow Would you approve that?

[MarkCallow]

CI should certainly build ktx_read and link ktxinfo and ktx2check against it. However during development I don't want to be building 2 libraries so I'd like the default build to be the ktx with the tools linking against its libktx.

Do you think we should include the read only library in the installers? Even if we do, these 2 tools should be linked against the full libktx to avoid having 2 libraries resident in memory.

[MarkCallow]

I've changed my mind about not having KTX_FEATURE_STATIC_LIBRARY appearing for iOS and Emscripten. Leave it the way it is now but please add an error should it be set false on these 2 platforms. After that I'll merge this PR.

[atteneder]

CI should certainly build ktx_read and link ktxinfo and ktx2check against it. However during development I don't want to be building 2 libraries so I'd like the default build to be the ktx with the tools linking against its libktx.

Do you think we should include the read only library in the installers? Even if we do, these 2 tools should be linked against the full libktx to avoid having 2 libraries resident in memory.

My thought was saving memory by using the smaller ktx_read, but in that case this does not make sense.

[atteneder]

Alright, KTX_FEATURE_STATIC_LIBRARY is now always present, but a proper error is shown in case it is misconfigured.

I quickly tested if a read-only WebAssembly variant makes sense, but the current version already offers no write capability (thus it's already very small).

[MarkCallow]

I quickly tested if a read-only WebAssembly variant makes sense, but the current version already offers no write capability (thus it's already very small).

I do expect to add write capabilities to the WebAssembly build in the future so people can write web tools to encode files. Please check that the Emscripten build disables writing in the same way as ktx_read, i.e. using the same compile options. However do not change the name of the Emscripten library at this time as I do not want to confuse existing users. We'll need to provide warning of the change.

[atteneder]

I now link ktx_js and msc_basis_transcoder_js against ktx_read.

Once write functionality in web is required, we should create additional targets and (optionally) set the KTX_FEATURE_WRITE compile flag on those.

[MarkCallow]

I cannot find any compile option being set to omit write from the Emscripten build. I think this functionality is missing from the .wasm module just because the wrapper does not have any write functions so they're never linked from libktx. Basically an example of why a static read-only library is not needed. When we make a .wasm module that supports write, at that time we must use the same ktx_read mechanisms in CMakeLists.txt to enable building of a read-only wrapper.

For now I think this PR is good to go.