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

Make pxrTargets.cmake relocatable (when built with TBB and OpenSubdiv) #3441

Open
wants to merge 8 commits into
base: dev
Choose a base branch
from

Conversation

tamaskenez
Copy link

@tamaskenez tamaskenez commented Nov 30, 2024

Description of Change(s)

The CMake targets now use TBB and OpenSubdiv as targets instead of absolute include and library paths.

Link to proposal (if applicable)

Fixes Issue(s)

The installed OpenUSD library was not relocatable because cmake/pxrTargets.cmake contained absolute paths of include directories and library files.

This PR solves the issue partially: it changes the way oneTBB and OpenSubdiv are used, if those dependencies are found by their CMake config-scripts (as opposed to a find-module).

Therefore, if OpenUSD is built only with the oneTBB (not the old TBB) and OpenSubdiv dependencies which provide a config-script (which is the case when building with build_usd.py), with this PR the installed OpenSubdiv library will be relocatable.

Checklist

[X] I have created this PR based on the dev branch

[X] I have followed the coding conventions

[ ] I have added unit tests that exercise this functionality (Reference:
testing guidelines)

[ ] I have verified that all unit tests pass with the proposed changes

[X] I have submitted a signed Contributor License Agreement (Reference:
Contributor License Agreement instructions)

@tamaskenez tamaskenez changed the title Make TBB and OpenSubdiv dependencies relocatable Make pxrTargets.cmake relocatable (when built with TBB and OpenSubdiv) Nov 30, 2024
@jesschimein
Copy link
Collaborator

Filed as internal issue #USD-10483

❗ Please make sure that a signed CLA has been submitted!

@jesschimein
Copy link
Collaborator

/AzurePipelines run

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@asluk asluk added the build Build-related issue/PR label Dec 2, 2024
@tamaskenez
Copy link
Author

I've submitted the CLA and I'll be looking into the build errors.

@tamaskenez tamaskenez force-pushed the relocatable_config_with_tbb_opensubdiv branch from 7d09fed to a714e51 Compare December 2, 2024 20:25
@tamaskenez
Copy link
Author

/AzurePipelines run

Copy link

Commenter does not have sufficient privileges for PR 3441 in repo PixarAnimationStudios/OpenUSD

@pixar-oss
Copy link
Member

/AzurePipelines run

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

Copy link
Contributor

@pmolodo pmolodo left a comment

Choose a reason for hiding this comment

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

Just to add my $.02 - overall, I think this looks great - in general I'm strongly for anything to moves more towards "modern cmake" with usage of targets instead of baked-in paths.

I had a few suggested tweaks, but they're minor, and I'd still be fine with accepting this as is.

Comment on lines 265 to 272
message(STATUS "OpenSubdiv found as config, OpenSubdiv_DIR is ${OpenSubdiv_DIR}")
foreach(t OpenSubdiv::osdCPU OpenSubdiv::osdGPU OpenSubdiv::osdCPU_static OpenSubdiv::osdGPU_static OpenSubdiv::OpenSubdiv)
if(TARGET "${t}")
message(STATUS "${t} is TARGET")
else()
message(STATUS "${t} is not TARGET")
endif()
endforeach()
Copy link
Contributor

Choose a reason for hiding this comment

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

These messages feel more like debugging messages than things that need to be displayed every build - do you think we could lower the message code from STATUS to VERBOSE or DEBUG?

Copy link
Author

Choose a reason for hiding this comment

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

I'm sorry, they are debugging messages and I removed them in my final commit. I set up a workflow on my fork and I was experimenting with solutions to fix the build error here.

Sorry for the noise, I left the PR in Draft state to indicate it's in progress.

Copy link
Author

Choose a reason for hiding this comment

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

removed

endforeach()
else()
find_package(OpenSubdiv 3 REQUIRED)
message(STATUS "OpenSubdiv found as module")
Copy link
Contributor

Choose a reason for hiding this comment

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

Ditto above - can we lower to VERBOSE or DEBUG?

Copy link
Author

Choose a reason for hiding this comment

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

also debugging, will be removed

Copy link
Author

Choose a reason for hiding this comment

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

removed

Comment on lines 26 to 31
if(TBB_DIR)
set(PXR_FIND_TBB_IN_CONFIG ON)
endif()
if(OpenSubdiv_DIR)
set(PXR_FIND_OPENSUBDIV_IN_CONFIG ON)
endif()
Copy link
Contributor

Choose a reason for hiding this comment

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

Personally, I would find this more readable if these variables were set in Packages.cmake, in the same branches where we first check to see if the config packages were found. (And also explicitly set to OFF if not found.)

I can see the thinking of wanting to restrict Pixar-specific variables to the pxr subdirectory - but really, everything in the cmake subdir is already very Pixar-specific, and there's already examples of setting PXR_XXX variables in there... so I'd rather it easier to read.

Copy link
Author

Choose a reason for hiding this comment

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

Thanks, changed in 08c8ca9

@@ -47,6 +47,16 @@ if(@PXR_ENABLE_PYTHON_SUPPORT@)
endif()
endif()

include(CMakeFindDependencyMacro)

if(@PXR_FIND_TBB_IN_CONFIG@)
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we replace this with:

if (NOT DEFINED PXR_FIND_TBB_IN_CONFIG)
    set(PXR_FIND_TBB_IN_CONFIG "@PXR_FIND_TBB_IN_CONFIG@")
endif()
if(PXR_FIND_TBB_IN_CONFIG)

I know there's already an established precedent of just doing the "bare" if(@PXR_VAR@), but I feel this makes the resulting pxrConfig.cmake less readable, and prevents downstream users from being able to check (or even override) PXR_FIND_TBB_IN_CONFIG directly themselves.

Copy link
Author

@tamaskenez tamaskenez Dec 2, 2024

Choose a reason for hiding this comment

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

I agree that lines like if(OFF) or even if() are cryptic. I like your suggestion but why do we need to check if it's defined, why not just setting it?

set(PXR_FIND_TBB_IN_CONFIG "@PXR_FIND_TBB_IN_CONFIG@")
if(PXR_FIND_TBB_IN_CONFIG)

or, what about a comment?

if(@PXR_FIND_TBB_IN_CONFIG@) # if(PXR_FIND_TBB_IN_CONFIG)

I'm fine with either one of the 3 above.

Copy link
Author

@tamaskenez tamaskenez Dec 2, 2024

Choose a reason for hiding this comment

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

I did the second option, please let me know if you prefer your original or the comment. 9decb4e

find_dependency(TBB @TBB_VERSION@ CONFIG)
endif()

if(@PXR_FIND_OPENSUBDIV_IN_CONFIG@)
Copy link
Contributor

Choose a reason for hiding this comment

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

Similar to above - can we replace with:

if (NOT DEFINED PXR_FIND_OPENSUBDIV_IN_CONFIG)
    set(PXR_FIND_OPENSUBDIV_IN_CONFIG "@PXR_FIND_OPENSUBDIV_IN_CONFIG@")
endif()
if(PXR_FIND_OPENSUBDIV_IN_CONFIG)

Copy link
Author

Choose a reason for hiding this comment

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

@tamaskenez tamaskenez marked this pull request as ready for review December 2, 2024 23:41
@tamaskenez tamaskenez requested a review from pmolodo December 3, 2024 06:28
@jesschimein
Copy link
Collaborator

/AzurePipelines run

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@tamaskenez
Copy link
Author

@pmolodo Could you please check this again, the checks pass and I addressed your suggestions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build Build-related issue/PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants