Bug 2055414
| Summary: | usd-devel is missing pxrTargets.cmake | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Nikita Musatov <not.a.whale> |
| Component: | usd | Assignee: | Luya Tshimbalanga <luya_tfz> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 35 | CC: | code, luya_tfz, negativo17 |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | usd-21.11-10.fc35 usd-22.03-8.fc36 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-04-20 19:09:40 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Nikita Musatov
2022-02-16 21:06:20 UTC
This seems to be “intentional” in USD-21.11/pxr/CMakeLists.txt: > if (NOT PXR_BUILD_MONOLITHIC) > install(EXPORT pxrTargets DESTINATION "cmake") > endif() Here is the PR that introduced that behavior: https://github.com/PixarAnimationStudios/USD/pull/252 A monolithic build is one with a single shared library instead of many separate ones. We currently do a monolithic build in Fedora. There is a relevant upstream issue: https://github.com/PixarAnimationStudios/USD/issues/1088 I found another issue that isn’t exactly about this, but may be relevant to what you are trying to do: https://github.com/PixarAnimationStudios/USD/issues/1025 ---- It seems like the only way we could resolve this in Fedora is to stop setting PXR_BUILD_MONOLITHIC=ON. Because that would change the libraries that need to be linked, it would be an ABI break, so it couldn’t happen in a stable release. It would also require a new downstream .so versioning patch, since the current one applies only to the monolithic library (https://bugzilla.redhat.com/show_bug.cgi?id=2019440#c8). Luya, what do you think? (In reply to Ben Beasley from comment #1) > > It seems like the only way we could resolve this in Fedora is to stop > setting PXR_BUILD_MONOLITHIC=ON. Because that would change the libraries > that need to be linked, it would be an ABI break, so it couldn’t happen in a > stable release. It would also require a new downstream .so versioning patch, > since the current one applies only to the monolithic library > (https://bugzilla.redhat.com/show_bug.cgi?id=2019440#c8). > > Luya, what do you think? I recently pushed USD 22.03 update in both Rawhide and Fedora 36. You can try the suggestion and see if that will fix the issue. > I recently pushed USD 22.03 update in both Rawhide and Fedora 36. You can
> try the suggestion and see if that will fix the issue.
Are you suggesting that 22.03 should fix this? (I don’t believe anything has changed upstream.)
Or are you suggesting that someone should make a PR that disables the monolithic build?
(In reply to Ben Beasley from comment #3) > > I recently pushed USD 22.03 update in both Rawhide and Fedora 36. You can > > try the suggestion and see if that will fix the issue. > > Are you suggesting that 22.03 should fix this? (I don’t believe anything has > changed upstream.) > > Or are you suggesting that someone should make a PR that disables the > monolithic build? Luya, could you please clarify when you have a chance? Thanks! I suggest the latter i.e. disable the monolithic build. Upon closer investigation, Blender’s build system is designed to designed to work only with a monolithic build of USD, so I think we’re going to have to stick with a monolithic build in Fedora. It seems like the `pxrConfig.cmake` that is currently installed with the package isn’t usable, because it is designed to work with the targets for the non-monolithic libraries. I’m not expert enough in CMake to offer a PR to USD upstream that would fix this properly. Would it be helpful if we at least removed the `pxrConfig.cmake` file from the RPM package, since it seems not to be usable? Other than that, all I can suggest is working with upstream to provide better CMake support for monolithic builds. (In reply to Ben Beasley from comment #6) > Upon closer investigation, Blender’s build system is designed to designed to > work only with a monolithic build of USD, so I think we’re going to have to > stick with a monolithic build in Fedora. > > It seems like the `pxrConfig.cmake` that is currently installed with the > package isn’t usable, because it is designed to work with the targets for > the non-monolithic libraries. I’m not expert enough in CMake to offer a PR > to USD upstream that would fix this properly. Would it be helpful if we at > least removed the `pxrConfig.cmake` file from the RPM package, since it > seems not to be usable? > > Other than that, all I can suggest is working with upstream to provide > better CMake support for monolithic builds. That sounds like a good idea and if they will change USD something and pxrConfig.cmake will work with the monolithic build you can return this file. FEDORA-2022-c87bba6546 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-c87bba6546 FEDORA-2022-ae41947c20 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-ae41947c20 FEDORA-2022-c87bba6546 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-c87bba6546` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-c87bba6546 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2022-ae41947c20 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-ae41947c20` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-ae41947c20 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2022-c87bba6546 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-c87bba6546` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-c87bba6546 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2022-ae41947c20 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-ae41947c20` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-ae41947c20 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2022-ae41947c20 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2022-c87bba6546 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-c87bba6546` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-c87bba6546 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2022-c87bba6546 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report. |