-
Notifications
You must be signed in to change notification settings - Fork 229
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix an issue with the generated KtxTargets.cmake #325
Conversation
@MarkCallow Can u pls review? |
Please create an issue. Note that there is a large change coming to the CMake files to add a libktx_read that can only read KTX files. I Plan to merge that PR (#324) first. You will have to rebase this after the merge if, as I expect it to be, the bug is still present. |
CMakeLists.txt
Outdated
@@ -195,7 +195,7 @@ target_include_directories( | |||
PUBLIC | |||
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include> | |||
$<INSTALL_INTERFACE:include> | |||
|
|||
PRIVATE | |||
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/lib/basisu/transcoder> | |||
$<INSTALL_INTERFACE:lib/basisu/transcoder> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if this line and all similar are really necessary. I've requested a review from @atteneder.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While this changes are not necessary, I agree it makes sense to strictly differentiate between public and private(internal) headers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am referring to the INSTALL_INTERFACE
line. lib/basisu/transcoder is not installed. It is purely internal to the libktx. Hence my question.
There shouldn't be any need to actually make and install a transcoder library. If shared libktx is being used I don't think anybody cares if the whole libktx is loaded into memory. If a static library is being used and only the transcoder is referenced, the linker will link only the transcoder functions into the application.
CMakeLists.txt
Outdated
@@ -329,7 +329,7 @@ set(KTX_BUILD_DIR "${CMAKE_BINARY_DIR}") | |||
|
|||
if(WIN32) | |||
target_link_libraries( | |||
ktx | |||
ktx PRIVATE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wasn't aware of this. I'd need to test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
libktx has references to functions in libzstd. If you are building a shared library these will cause libzstd to be linked into the shared libktx. If static, the app needs to link with libzstd to satisfy the references.
CMakeLists.txt
Outdated
@@ -396,7 +401,7 @@ if(KTX_FEATURE_VULKAN) | |||
) | |||
target_include_directories( | |||
ktx | |||
PUBLIC | |||
PRIVATE | |||
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/lib/dfdutils> | |||
$<INSTALL_INTERFACE:lib/dfdutils> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is also going to be needed by the app when linking with a static library which is a problem as there is currently no separate release of the dfdutils library.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do users of KTX need to use dfdutils (dfd.h) directly commonly?
A clean solution could be to create a CMake config for dfdutils as well and link to its CMake target.
Users who need dfdutils directly could direclty refer to it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quite possibly, if the app wishes to examine the DFD. At present only a small part of the information it contains is made available through the libktx API.
I agree we should make a CMake config for it, as you suggest @atteneder. dfdutils is included via git subrepo
from https://github.com/KhronosGroup/dfdutils. I need to push some recent additions and fixes back there and we should add the CMake config there.
CMakeLists.txt
Outdated
@@ -195,7 +195,7 @@ target_include_directories( | |||
PUBLIC | |||
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include> | |||
$<INSTALL_INTERFACE:include> | |||
|
|||
PRIVATE | |||
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/lib/basisu/transcoder> | |||
$<INSTALL_INTERFACE:lib/basisu/transcoder> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While this changes are not necessary, I agree it makes sense to strictly differentiate between public and private(internal) headers.
CMakeLists.txt
Outdated
@@ -329,7 +329,7 @@ set(KTX_BUILD_DIR "${CMAKE_BINARY_DIR}") | |||
|
|||
if(WIN32) | |||
target_link_libraries( | |||
ktx | |||
ktx PRIVATE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wasn't aware of this. I'd need to test.
CMakeLists.txt
Outdated
@@ -396,7 +401,7 @@ if(KTX_FEATURE_VULKAN) | |||
) | |||
target_include_directories( | |||
ktx | |||
PUBLIC | |||
PRIVATE | |||
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/lib/dfdutils> | |||
$<INSTALL_INTERFACE:lib/dfdutils> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do users of KTX need to use dfdutils (dfd.h) directly commonly?
A clean solution could be to create a CMake config for dfdutils as well and link to its CMake target.
Users who need dfdutils directly could direclty refer to it.
@@ -22,7 +22,7 @@ target_include_directories( | |||
PUBLIC | |||
inc | |||
PRIVATE | |||
$<TARGET_PROPERTY:ktx,INTERFACE_INCLUDE_DIRECTORIES> | |||
$<TARGET_PROPERTY:ktx,INCLUDE_DIRECTORIES> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd appreciate consistent indentation. Same in tests.cmake:42
PR #324 has been merged. Please rebase this against the new master, make the changes necessary for the static library case and remove lib/basisu/transcoder from the INSTALL_INTERFACE. We will work separately on a CMake config for the dfdutils. Note the dfdutils will be in the library archive sohat an application needs in order to use them are |
Please update this PR. |
# Conflicts: # CMakeLists.txt
Travis CI has not built this or the other open PR. I don't at present know why. There has been no change in the .travis.yml since the last time Travis did a PR build. I can't merge this until we have a successful build. If you have any ideas, please let me know. |
The missing Travis PR build has something to do with Khronos's Travis membership. It will probably take a few days to sort out. Please wait. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am repeating my question from my first review. Please answer.
Sorry for late reply (I'm preparing a relocation myself now). |
Thanks for the explanation. Now we have to wait for Khronos to resolve the issue around Travis CI builds. Note there is a PR #335 adding support for building on Android which makes many changes to the CMake files some of which I expect will overlap with these. I plan to merge this PR first as it has been open for some time. That means PR #335 will need rebasing. |
Oh, I see you already cleared everything up. Nonetheless I tested on Linux and found no issues! |
Khronos has resolved the issue with Travis CI. I triggered a redelivery of the webhook payload for the latest commit in this PR but it has not triggered a build. @UX3D-becher please push something to this PR to trigger a build so we can test the Linux, macOS and Web builds with these changes. |
Please do a push to trigger a Travis CI build so we can check the iOS, Linux & macOS builds. I want to get this PR merged. |
You need to make a small change and push it to this repo to trigger a Travis-CI build. I have tried to redelivering the webhook requests from the previous commits from GitHub but it is not working. Until we get successful iOS, Linux, macOS and web builds (all of which are done on Travis) I cannot merge this PR. |
@UX3D-becher trigger a build or else I will have to close this PR without merging. |
Unfortunately Khronos seems have used up all its credits with Travis CI so the builds have stopped again. It is infuriating. Trying to get it resolved. I may need you to push a commit again. Perhaps lack of credits is the reason re-sending the WebHook message for a previous commit failed to trigger a build. I'll try that again first once the problem is sorted. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Been away a couple of days. Sorry for the delay. The change looks good to my limited knowledge of Android. Is zstd included as a standard feature of Android? I'm going to request a review from Andreas.
The problem blocking the macOS & Linux builds has reportedly been fixed, however redelivering GitHub webhook payloads to Travis has no visible effect so I have to again ask you to push another commit to this PR to trigger a build. Please do it as soon as possible. |
I cleaned some whitespace to trigger a build, hopefully these changes were in your interest anyway |
Thanks for making it easier to use libktx is other projects. |
Make it possible to use the find_package functionality of cmake to use libktx as imported target.
Make it possible to use the find_package functionality of cmake to use libktx as imported target.
Make it possible to use the find_package functionality of cmake to use libktx as imported target.
Fixes issue #326
In this pull request we changed the problematic dependencies of the ktx target in the root CMakeLists.txt from
PUBLIC
toPRIVATE
and fixed configuration errors in other cmake files. These errors mainly stem from the use of the INTERFACE_INCLUDE_DIRECTORIES property of the ktx that after the above change does not contain the private include paths any more.