SG-41117: cmake use cy files for dependency versions and add experimental support CY2025 and CY2026 #985
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mcoliver
force-pushed
the
maint-cmake-move-vars-to-cy-files
branch
from
943ee25 to
b33ee20
Compare
Helps clarify and centralize changes between CY years and what each year needs. Future CY years can be more easily supported by adding a new cmake file for the CY year. Signed-off-by: Michael Oliver <[email protected]>
Updated the docs to reference the dependencies as listed by the vfx platform Signed-off-by: Michael Oliver <[email protected]>
Signed-off-by: Michael Oliver <[email protected]>
Moved numpy version to an env var to conform to vfxplatform.com CY needs. Minor formating updates as well for readability Signed-off-by: Michael Oliver <[email protected]>
Makes adding future years easier. Will need to change when/if qt7 is announced. Signed-off-by: Michael Oliver <[email protected]>
OpenEXR build will now reference env vars from the CYYEAR.cmake file. Put in stub files for the patches for each openexr year so the patch command does not fail. TODO: need to manually go through and create the patches. After briefly looking at the patch I wonder if using black is the right call here and if we would be better off invalidating the entire frame rather than putting in black for invalid lines. Signed-off-by: Michael Oliver <[email protected]>
boost, imath, ocio, oiio, abd openssl will now be built based on env vars from the CYYEAR.cmake file Signed-off-by: Michael Oliver <[email protected]>
Moved some patch files to a subdirectory and put in stub patches for newer versions of python. TODO: Update the patch files for each python version. Signed-off-by: Michael Oliver <[email protected]>
standardize with other dependencies that rely on .zip like openexr Signed-off-by: Michael Oliver <[email protected]>
do not need to set vars that are already established now that we read them from a CY cmake file. Signed-off-by: Michael Oliver <[email protected]>
TODO Need to generate patch files for newer versions of python to work. Rolling back for now. Signed-off-by: Michael Oliver <[email protected]>
added vars for imath version libs Signed-off-by: Michael Oliver <[email protected]>
Signed-off-by: Michael Oliver <[email protected]>
using SET is fine Signed-off-by: Michael Oliver <[email protected]>
RV was 7.5GB on Release build. Trying to slim it down. Signed-off-by: Michael Oliver <[email protected]>
Currently it was setting RV_VFX_PLATFORM based on finding Qt. The logic should be to set the Qt version based on the CY requirements. We also need to support 6.8 for CY2026 and the current logic prevented that. Also added a supporting function to ask for the CY year when sourcing rvcmds if RV_VFX_PLATFORM has not been previously set. Signed-off-by: Michael Oliver <[email protected]>
need to explicitly pass the env to the python process Signed-off-by: Michael Oliver <[email protected]>
NumPy from vfxplatform conflicts with PySide2 requirements of < 1.23. Commenting for future reference Signed-off-by: Michael Oliver <[email protected]>
fix quoting for patch file Signed-off-by: Michael Oliver <[email protected]>
Build paths were empty as they were echod before rvrelease was run. Updating paths ahead of time shows the proper output Signed-off-by: Michael Oliver <[email protected]>
TODO need to generate these but for now let's leave them out to prevent a "file not found" error when they exist but are empty Signed-off-by: Michael Oliver <[email protected]>
QT5 or QT6 in env vars is messy and probably not necessary. We should just be able to set a single location for Qt. But I'm leaving the others for now just in case. Should probably get cleaned up though. Signed-off-by: Michael Oliver <[email protected]>
Probably not needed down the road but adding for now pending future cleanup Signed-off-by: Michael Oliver <[email protected]>
Signed-off-by: Michael Oliver <[email protected]>
…atements. Used QT65 in the event we need different code for QT68 Signed-off-by: Michael Oliver <[email protected]>
Signed-off-by: Michael Oliver <[email protected]>
… Should probably updated the variable name to be more indicative of the fact that it's specific to the Qt version but for now will leave it. Signed-off-by: Michael Oliver <[email protected]>
Signed-off-by: Michael Oliver <[email protected]>
…years. Signed-off-by: Michael Oliver <[email protected]>
Signed-off-by: Michael Oliver <[email protected]>
These are pretty common vars needed for setting library names. Could use more robust logic here as sometimes versions are passed that have underscores X_X or non standard X.X.X version numbering schemes. Signed-off-by: Michael Oliver <[email protected]>
…LES macro Signed-off-by: Michael Oliver <[email protected]>
Signed-off-by: Michael Oliver <[email protected]>
Signed-off-by: Michael Oliver <[email protected]>
Signed-off-by: Michael Oliver <[email protected]>
Contributor
Author
|
sounds good. I started migrating, and then accidentally just pushed to
this branch instead of a new one. Apologies. Should I pull it out or
should we include it? For ffmpeg I'd also like to make a slight
modification to the logic to allow users to use any ffmpeg version they
wish to use (experimental and unsupported of course).
…On Fri, Nov 14, 2025 at 11:37 AM Cédrik Fuoco ***@***.***> wrote:
*cedrik-fuoco-adsk* left a comment (AcademySoftwareFoundation/OpenRV#985)
<#985 (comment)>
I think I would move all non-VFX platforms dependencies into a
CYCOMMON.cmake.
Here's the list (Will have to double check to make sure):
aja
atomic_ops
bmd
dav1d
doctest
expat
Ffmpeg
gc
glew
Imgui
Jpegturbo
Nanobind
OpenImageIO
Openjpeg
Openjph
Openssl
Pcre2 (windows only)
Pyimgui
Pyimplot
Raw
Spdlog
Tiff
Webp
Zlib
Vcpkg
OTIO
There are special cases like FFmpeg where the extra logic to select
between 6, 7 or 8 will have to move to CYCOMMON.cmake too.
—
Reply to this email directly, view it on GitHub
<#985 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEX32IDV4LLAEATI5K4II334YVQJAVCNFSM6AAAAACL56BDTOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMZUGI4DIMBSGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Signed-off-by: Michael Oliver <[email protected]>
Signed-off-by: Michael Oliver <[email protected]>
Signed-off-by: Michael Oliver <[email protected]>
Signed-off-by: Michael Oliver <[email protected]>
Signed-off-by: Michael Oliver <[email protected]>
Contributor
|
Personally, I think it is manageable and I like having everything in one go. What do you think @eloisebrosseau @mcoliver Can you really do that for FFmpeg? We have special logic to set the right names for all the FFmpeg librairies. How are you going to handle that with any FFmpeg version? |
We'd like the specific CYXXX.cmake to overwrite the versions in CYCOMMON.cmake if needed. Signed-off-by: Michael Oliver <[email protected]>
Signed-off-by: Michael Oliver <[email protected]>
copy and paste got me again Signed-off-by: Michael Oliver <[email protected]>
Cleans up the ffmpeg.cmake file and moves lib versions to cycommon Signed-off-by: Michael Oliver <[email protected]>
Signed-off-by: Michael Oliver <[email protected]>
needs a v Signed-off-by: Michael Oliver <[email protected]>
Contributor
Author
Contributor
Contributor
|
We tested it locally, and we are ready to merge it. It would be great if you have time to fix the conflicts. @mcoliver If you don't have time, I can take care of it, but I'll need to create a new PR since I won't be able to write in your branch. |
Signed-off-by: Michael Oliver <[email protected]>
Contributor
Author
Conflicts resolved |
cedrik-fuoco-adsk
approved these changes
Nov 26, 2025
Contributor
cedrik-fuoco-adsk
left a comment
cedrik-fuoco-adsk
left a comment
There was a problem hiding this comment.
Thank you @mcoliver for the great contribution!
cedrik-fuoco-adsk
merged commit 29db6a5
into
AcademySoftwareFoundation:main
19 checks passed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summarize your change.
Moved hardcoded versions for various dependendencies out of individual cmake files and into a centralized file based on CY year. There were also changes made to allow for years beyond 2024 rather than having to hardcode values for each year in various build files throughout the repo.
Describe the reason for the change.
The current codebase has checks for 2023 or 2024 littered across many files and it makes it difficult to understand what needs to be updated for each CY year and where you do it. The code was also difficult to follow with macros defining vars for various years.
With this setup you can create a new CYYEAR.cmake file, copy the old one, update version numbers and even diff between them. It makes it much easier to understand where to go to update packages. Additionally it allows for things like CY2099.cmake which can have the most current releases of packages (perhaps ahead of a CY official designation) for people who like to run the latest dependencies with performance improvements and bug fixes.
Describe what you have tested and on which operating system.
Builds 2023, 2024, and 2025 have been verified on macOS.
Add a list of changes, and note any that might need special attention during the review.
Other discoveries
RV builds on macOS still want to find things in /opt/homebrew. This can easily cause build errors for users that have things like openexr installed through homebrew. You can see this by greping for
/opt/homebrewin the_builddirectory. I tried various cmake vars to tell cmake to ignore /opt/homebrew but could never seem to get any to work. Additionally there are things in homebrew that the build relies on like xz so you don't want to ignore everything. The problem is if something like openexr4.3.0 is installed with homebrew, cmake for 2024 will attempt to link to that rather than the 3.2 that was compiled for that CY year. For me I had to uninstall a bunch to get the build to work properlyThe resulting size of the RV.app build is quite large. I believe it can be significantly trimmed down and will do that in a different PR.
If possible, provide screenshots.