Skip to content

Conversation

@dgovil
Copy link
Collaborator

@dgovil dgovil commented Feb 26, 2024

Edit: As requested by @meshula , I'll be splitting up this PR into the smaller constituent parts so we can land them individually.

I will list them here so it's easy to follow along with progress. I am listing the proposed bits here, and will link them to actual PRs as they go up. These are listed in no particular order. They will be checked off as they are merged.

They are nested based on their dependencies

  • TempDirectory fixes : Makes sure that USD operations write to the containerized temp directory locations
  • Extract TBB Patches : TBB requires patches for each embedded platform. This may not be required after porting to OneTBB (Not sure), but we should move them into Apple Utils to avoid cluttering up the main build code
    • Simulator Support : Support for Simulator targets for people testing without devices.
  • Code Signing Improvements : Improve handling of automatic code signing, especially to handle frameworks
  • Build as Framework: Enable building targets as frameworks
  • CCache Support : Enables faster builds which is important when building for multiple targets (this is optional but its a huge speedup)

Description of Change(s)

This PR enables building of USD as a Framework.
A framework build puts the output files into a directory structure which allows them to be included easily in apps on macOS, iOS and visionOS. The steps to use it are included in the README but are repeated here in brief:

  1. User drags the Framework directory into their project target. This automatically sets up linkage.
  2. User sets it to Embed and Sign in the app

Frameworks are enabled automatically for Apple embedded platforms (iOS, visionOS).
Framework builds default to Monolithic because a framework may only include one dylib within it. Shared builds can still be enabled for some dev purposes, but aren't officially supported.

Experimental Feature

I request that the feature be marked as Experimental in the README, because I anticipate changes might be needed in the future to streamline how this works, such as not requiring the dependencies to be statically built. I think the current state of the PR will unblock the majority of people asking for this feature however and the changes I anticipate might be quite long term.

This incorporates some work by Maddy Adams and @meshula . The changes are largely non-invasive and are listed below:

Core Code Changes

  1. Adds a post build step with a zsh script that will construct the Framework bundle.
  2. Changes to the Plugin and usdMtlx registry to find their respective resources within the Framework
  3. Enable building statically against TBB and OpenSubdiv.
  4. New options in the CMake to handle framework build configuration

Build Script Changes

  1. Added argument to build as Framework (or disable) with --build-apple-framework and --no-build-apple-framework
  2. Added --prefix-framework-headers to opt-in to prefixing the headers
  3. Added support to apple_utils.py to orchestrate an XCFramework build, that combines multiple targets into one framework.
  4. Added support for Simulator targets
  5. Allow shared/monolithic builds arg to allow a default based on other args.
  6. Build Dependencies (MaterialX, TBB) as static when building monolithic
  7. Allow users to pass in code signing ID manually
  8. Improved Codesigning identity lookup speeds+reliability for both framework and non-framework builds
  9. Setup signing for dependencies automatically when using Xcode target

Header Notes
Framework headers are automatically discovered when prefixed by the framework name.
This requires the user to build with --prefix-framework-headers
E.g instead of #include <pxr/pxr.h> you would do #include <OpenUSD/pxr/pxr.h>

If someone wants to avoid the prefixed behavior, they have to manually add the Header directory to their targets SYSTEM_HEADER_SEARCH_PATHS .

  • I have verified that all unit tests pass with the proposed changes
  • I have submitted a signed Contributor License Agreement

@dgovil dgovil force-pushed the ios_core_frameworks branch from bc56f55 to 5f321b9 Compare February 26, 2024 18:54
@jesschimein
Copy link
Collaborator

Filed as internal issue #USD-9360

@jesschimein
Copy link
Collaborator

/AzurePipelines run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@dgovil dgovil force-pushed the ios_core_frameworks branch 2 times, most recently from 1664609 to 4a0f035 Compare February 29, 2024 03:05
@jesschimein
Copy link
Collaborator

/AzurePipelines run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@meshula
Copy link
Member

meshula commented Jun 17, 2024

@dgovil Could I ask you to pop in a note that reports when you are building a framework here?

Building with settings:
  USD source directory          /Users/nick/dev/usd
  USD install directory         /Users/nick/usd-dyfw-240616
  3rd-party source directory    /Users/nick/usd-dyfw-240616/src
...

@jesschimein
Copy link
Collaborator

/AzurePipelines run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@meshula
Copy link
Member

meshula commented Jun 18, 2024

Apologies @dgovil I was meaning to merge locally and got the <- -> icons backwards in the interface. Please force push to overwrite my inadvertent commit when you are ready to update.

@dgovil dgovil force-pushed the ios_core_frameworks branch from e07ce73 to 352d4d6 Compare June 18, 2024 18:14
@dgovil
Copy link
Collaborator Author

dgovil commented Jun 18, 2024

@meshula I rebased the latest on top of dev+ios_core PR. I overwrote your changes to my branch.
I added the print out in the build for the Building with settings: section. I already had a description of how to pull in the framework. It also includes the MaterialX copy over as well.

@meshula
Copy link
Member

meshula commented Jun 18, 2024

Thanks for fixing the mishap and adding the Mx bits!

@dgovil dgovil force-pushed the ios_core_frameworks branch from 352d4d6 to 947efa1 Compare August 16, 2024 18:51
@jesschimein
Copy link
Collaborator

/AzurePipelines run

@azure-pipelines
Copy link

Pull request contains merge conflicts.

@dgovil dgovil force-pushed the ios_core_frameworks branch from 390e3af to 8d23ab3 Compare August 20, 2024 20:54
@jesschimein
Copy link
Collaborator

/AzurePipelines run

@azure-pipelines
Copy link

Pull request contains merge conflicts.

@dgovil
Copy link
Collaborator Author

dgovil commented Aug 21, 2024

Currently refactoring this on top of the iOS imaging branch and the latest dev, so in flux for the moment.

@jesschimein
Copy link
Collaborator

/AzurePipelines run

@azure-pipelines
Copy link

Pull request contains merge conflicts.

@dgovil dgovil mentioned this pull request Aug 22, 2024
2 tasks
@jesschimein
Copy link
Collaborator

/AzurePipelines run

@azure-pipelines
Copy link

Pull request contains merge conflicts.

@dgovil
Copy link
Collaborator Author

dgovil commented Aug 23, 2024

Rebased this PR on the imaging branch.
I've also worked on making this a fully monolithic build so that it is a kosher framework. This means that you get a single (massive) framework that includes OpenUSD/OpenSubdiv/TBB/MaterialX. That may not be to everyones taste, but the alternative would be a framework per dylib which is a fairly sizable uplift to put in USD today (but something we could drive towards longterm)

It is still possible to build as a non-monolithic build, but I am not focusing on that setup because frameworks expect a single dylib per framework and we'd have something like ~70 frameworks going that route. Instead, long term, we can work with each dependency to add monolithic+framework builds to them as well, and then tease things apart here.

It also allows for building for simulator (but isn't super well tested)

My todos before I think this is ready is:

[] Make sure the USD build can load all the plugins that are part of it. Specifically HD etc...
[] Make sure that MaterialX can load its shaders from the resources directory

Potentially, I want to see if its possible to modify the headers to avoid needing to add the header search path manually.

@meshula
Copy link
Member

meshula commented Aug 23, 2024

Looking promising!

Potentially, I want to see if its possible to modify the headers to avoid needing to add the header search path manually.

If you can solve that one, that would be fantastic!

Could I ask you to drop a link in to point us at

Rebased this PR on the imaging branch.

Given the evolution of the ios + imaging work, it would be helpful to have a link to the branch out here in the main thread.

@dgovil
Copy link
Collaborator Author

dgovil commented Aug 23, 2024

Yep, added a link to the main body above but also adding it here #3215

@jesschimein
Copy link
Collaborator

/AzurePipelines run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@jesschimein
Copy link
Collaborator

/AzurePipelines run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@dgovil dgovil force-pushed the ios_core_frameworks branch from 4f54b2a to 47da75e Compare November 23, 2024 18:59
@jesschimein
Copy link
Collaborator

/AzurePipelines run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@jesschimein
Copy link
Collaborator

/AzurePipelines run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@jesschimein
Copy link
Collaborator

/AzurePipelines run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@dgovil dgovil force-pushed the ios_core_frameworks branch from 12c2357 to 0729140 Compare January 27, 2025 18:58
@dgovil dgovil force-pushed the ios_core_frameworks branch from d1bf209 to 50f2977 Compare January 27, 2025 19:14
@jesschimein
Copy link
Collaborator

/AzurePipelines run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).


if context.buildTarget == apple_utils.TARGET_VISIONOS:
# Create visionOS config from iOS config
if MacOSTargetEmbedded(context) and context.buildTarget != apple_utils.TARGET_IOS:
Copy link
Member

Choose a reason for hiding this comment

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

When GCD is available as a work backend let's get rid of this patching on vision os

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The GCD work will still require TBB for the data constructs unfortunately

the file does not match.
Returns the absolute path to the directory where files have
Returns the absolute path to the directory where files have
Copy link
Member

Choose a reason for hiding this comment

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

let's get ws fixes out of this pr

cmakeOptions = ['-DMATERIALX_BUILD_SHARED_LIBS=ON',
'-DMATERIALX_BUILD_TESTS=OFF'
]
cmakeOptions = ['-DMATERIALX_BUILD_TESTS=OFF']
Copy link
Member

Choose a reason for hiding this comment

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

rebase on 25.05 some of this will disappear

default=codesignDefault, action="store_true",
help=("Enable code signing for macOS builds "
"(defaults to enabled on Apple Silicon)"))
group.add_argument("--codesign-id", dest="macos_codesign_id", type=str)
Copy link
Member

Choose a reason for hiding this comment

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

can we clean up code signing separately?

buildMayapyTests=("On" if context.buildMayapyTests else "Off"),
buildAnimXTests=("On" if context.buildAnimXTests else "Off"),
enableHDF5=("On" if context.enableHDF5 else "Off"))
enableHDF5=("On" if context.enableHDF5 else "Off"),
Copy link
Member

Choose a reason for hiding this comment

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

we're dropping hdf5 support anyway

endif()

# Setup CCache for C/C++ compilation
if(PXR_ENABLE_COMPILER_CACHE)
Copy link
Member

Choose a reason for hiding this comment

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

different PR

#else
#define ARCH_OS_OSX
#endif
#if TARGET_OS_SIMULATOR
Copy link
Member

Choose a reason for hiding this comment

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

separate PR?

_AppendPathList(&result, buildLocation, binaryPath);
_AppendPathList(&result, pluginBuildLocation, binaryPath);

#ifdef PXR_BUILD_APPLE_FRAMEWORK
Copy link
Member

Choose a reason for hiding this comment

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

can we configure this in cmake to eliminate the ifdef here

}
else {
metalColorAttachment.loadAction =
metalColorAttachment.loadAction =
Copy link
Member

Choose a reason for hiding this comment

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

separate

@dgovil dgovil changed the title Apple: Enable building as an Apple Framework [OLD] Apple: Enable building as an Apple Framework Jul 8, 2025
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.

3 participants