Decrease rebuilds of plug-ins between USD versions

Community Build and Deployment
1

I’m interested to find ways we can reduce rebuilds of our plug-ins and libraries consuming USD on changes to our USD build. I found the PR that makes the no-python build of USD ABI compatible with Python builds which is a helpful step for us.

I saw the PXR_INTERNAL_NAMESPACE by default is set to " pxrInternal_v0_23" , e.g. for the 23.x releases.

I’m guessing this means the intent is to keep ABI compatibility between the 0.23.x releases, but potentially break compatibility on 0.24.x. Does that sound right?

Assuming that’s right, is the goal to get ABI compatibility across the major releases, i.e., compatibility only breaks between 1.x and 2.x?

2

Personally I haven’t found USD to be reliably ABI stable across any version heuristic. I don’t believe the policy is outlined anywhere and if it’s not, I wouldn’t rely on it. Specifically, USD does not follow semver, or any kind of major/minor versioning. It is effectively a rolling release.

I’m actually not a fan myself of the current namespacing logic because it feels somewhat arbitrary. Since the namespace changes per year, it means that suddenly between 23.11 and 24.3, you get a linker break even if the ABI might not have changed. But an ABI change between 23.2 and 23.11 would cause a break even though the namespace has changed.

I almost think it would be better to have a fully versioned namespace.

Anyway, sorry, long winded way of saying I would make no expectations of ABI or API stability as a concrete policy at this time.

One thing you could do is set a namespace without a version. This would only work for cases where something else isn’t expecting a specific namespace, but it would mean that you’d have fewer rebuilds necessary between versions.

3

Thanks for your response.

I almost think it would be better to have a fully versioned namespace.

This is currently how we treat it. However, I did a test build of an asset resolver plugin and found it compatible between 23.2 and 23.11. The prospect of having to rebuild less often was attractive, though you get less lucky as you use more parts of the USD API.