Skip to content
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

Merged
merged 11 commits into from
Dec 11, 2020

Conversation

UX3D-becher
Copy link
Contributor

@UX3D-becher UX3D-becher commented Oct 8, 2020

Fixes issue #326

In this pull request we changed the problematic dependencies of the ktx target in the root CMakeLists.txt from PUBLIC to PRIVATE 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.

@CLAassistant
Copy link

CLAassistant commented Oct 8, 2020

CLA assistant check
All committers have signed the CLA.

@UX3D-nopper
Copy link

@MarkCallow Can u pls review?

@MarkCallow
Copy link
Collaborator

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>
Copy link
Collaborator

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.

Copy link
Contributor

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.

Copy link
Collaborator

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
Copy link
Collaborator

@MarkCallow MarkCallow Oct 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This and related lines will have to change after PR #324 is merged as, if the built library is a static library (an option added by PR #324), libzstd will be required by the application.

Copy link
Contributor

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.

Copy link
Collaborator

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>
Copy link
Collaborator

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.

Copy link
Contributor

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.

Copy link
Collaborator

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>
Copy link
Contributor

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
Copy link
Contributor

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>
Copy link
Contributor

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>
Copy link
Contributor

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

@MarkCallow
Copy link
Collaborator

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 dfd.h and khr_df.h. We should add those to the installers and the INSTALL_INTERFACE here. Please add these changes to this PR.

@MarkCallow
Copy link
Collaborator

Please update this PR.

@MarkCallow
Copy link
Collaborator

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.

@MarkCallow
Copy link
Collaborator

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.

Copy link
Collaborator

@MarkCallow MarkCallow left a 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.

CMakeLists.txt Show resolved Hide resolved
CMakeLists.txt Show resolved Hide resolved
CMakeLists.txt Show resolved Hide resolved
@atteneder
Copy link
Contributor

Sorry for late reply (I'm preparing a relocation myself now).
I try to have a look in the afternoon.

@MarkCallow
Copy link
Collaborator

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.

@atteneder
Copy link
Contributor

Sorry for late reply (I'm preparing a relocation myself now).
I try to have a look in the afternoon.

Oh, I see you already cleared everything up. Nonetheless I tested on Linux and found no issues!
Thanks!

@MarkCallow
Copy link
Collaborator

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.

@MarkCallow
Copy link
Collaborator

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.

@MarkCallow MarkCallow mentioned this pull request Nov 21, 2020
@MarkCallow
Copy link
Collaborator

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.

@MarkCallow
Copy link
Collaborator

@UX3D-becher trigger a build or else I will have to close this PR without merging.

@MarkCallow
Copy link
Collaborator

MarkCallow commented Dec 2, 2020

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.

Copy link
Collaborator

@MarkCallow MarkCallow left a 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.

@MarkCallow
Copy link
Collaborator

MarkCallow commented Dec 3, 2020

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.

@UX3D-becher
Copy link
Contributor Author

I cleaned some whitespace to trigger a build, hopefully these changes were in your interest anyway

@MarkCallow MarkCallow merged commit 9131fba into KhronosGroup:master Dec 11, 2020
@MarkCallow
Copy link
Collaborator

Thanks for making it easier to use libktx is other projects.

KaperD pushed a commit to KaperD/KTX-Software that referenced this pull request Feb 22, 2024
Make it possible to use the find_package functionality of cmake to use libktx as imported target.
KaperD pushed a commit to KaperD/KTX-Software that referenced this pull request Feb 22, 2024
Make it possible to use the find_package functionality of cmake to use libktx as imported target.
KaperD pushed a commit to KaperD/KTX-Software that referenced this pull request Feb 22, 2024
Make it possible to use the find_package functionality of cmake to use libktx as imported target.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants