It's hard to build this project about ktx-software HOT 7 CLOSED

@atteneder I'm mostly interested in the command-line utility, so my preferred way would be either a binary release from GH, or building my own via CMake - preferably with as little third-party dependency setup and using as straightforward of a config as possible, e.g. cmake & cmake --build from root.

from ktx-software.

After generating the make files with CMake you can run

make toktx

to build toktx. Similarly

make libktx.gl

will build the loading library though, as it will be built as a dependency of toktx, this should be unnecessary.

Neither libktx and toktx will trip over those dependencies. Only the vkloadtests target depends on vulkan/vulkan.h and the VulkanSDK. Only the various documentation targets depend on doxygen. There is nothing I can do about these dependencies.

I'm not sure what I can do to make this easier. Is there a way to tell CMake to make the default target something other than all? If there is, I suppose the answer is to create a pseudo target that builds libktx.gl, ktx2check, ktx2ktx2 ktxinfo, ktxsc and toktx. All these build without those dependencies.

Did you read BUILDING.md? If so was it help or hindrance? Looking at it, now I see it only explains how to do partial builds for the build/make/linux files. I can certainly add similar info for the CMake option. I can also add a note about the build/make/linux files needing gyp. As I have gyp installed, I hadn't noticed that. I'm sorry.

Feel free to submit a PR with improvements to BUILDING.md.

I'm open to any other suggestions or PRs you have for improvement.

from ktx-software.

From CMake-generated projects, doing make toktx still requires Vulkan headers from what it looks like:

[  0%] Building C object CMakeFiles/libktx_gl.dir/mnt/c/work/KTX-Software/lib/texture1_vvtbl.o
In file included from /mnt/c/work/KTX-Software/lib/texture1_vvtbl.c:33:
/mnt/c/work/KTX-Software/lib/vk_funcs.h:39:10: fatal error: vulkan/vulkan.h: No such file or directory
   39 | #include <vulkan/vulkan.h>
      |          ^~~~~~~~~~~~~~~~~

With CMake, the way I've seen other projects structured is that optional dependencies (tests, documentation) are behind separate configuration switches (BUILD_DOCS, BUILD_TESTS, etc.). It's also possible in theory to detect the presence of tools like Doxygen during CMake install - I've seen many projects use this but I've also seen package manager maintainers advise against that so I'm not sure if this is considered a good practice...

I did read BUILDING.md - it didn't really help but it wasn't a hindrance in that the build instructions for Linux are ones that I intuitively expected after doing ls build.

from ktx-software.

After installing libvulkan-dev and libgl1-mesa-dev to get Vulkan SDK and libGL.so toktx did build successfully. It seems odd to me that a command-line texture conversion tool requires Vulkan SDK and OpenGL to build - would you be open to accepting changes that remove these dependencies?

from ktx-software.

First let me apologize for misremembering. As you found, building libktx requires vulkan/vulkan.h. This is for compiling the API to the Vulkan loader. It does not require any other parts of the Vulkan SDK. libgl.so is required by libktx because it is a DLL and is not run-time retrieving the GL function addresses. That is something I want to fix.

would you be open to accepting changes that remove these dependencies?

Absolutely. I'm not sure it is practical to remove the vulkan/vulkan.h dependency as the loader API uses several Vulkan types and structures whose definitions would have to be duplicated within ktxvulkan.h likely leading to problems for app's using the Vulkan loader and including vulkan/vulkan.h for their use of Vulkan.

from ktx-software.

I'm going to close this for now in favor of #134, it doesn't make too much sense to work on build config with that in the works.

from ktx-software.

Hi @zeux,

I'm working on an easy to use CMake config and would value your input. What would be your preferred way and why:

• Use a pre-built library installed via Installer or packaging system (homebrew, apt, choco, ...)
• Build your own locally (via Makefiles/CMake) and copy results
• Integrate CMake target into your project's CMake config
• Some other way?

I think first variant + a FindKTX CMake module would be most convenient and second and third variants let you customize the build.

Thanks in advance,
Andi

from ktx-software.