Compatibility with multiple PhysX versions

[shaneasd]

TLDR:
My request is that, going forward, my software would be able to link against two versions of PhysX without me having to make substantial code changes to the PhysX code.

Explanation

I work with a large code base with many products that use PhysX. For each product a PhysX upgrade is expensive for two reasons. One is the API changes which require code to be tweaked or rewritten. The other is behavior changes which break regression tests. I'm not complaining that either of these changes exist. I can appreciate that forward progress means not being too tightly bound by what already exists.

However, we would like to be able to upgrade one product to PhysX 5 without having to upgrade all of them. For existing products (some 10 years old) there is less driver to upgrade the version of PhysX. The structure of our codebase means that all versions of PhysX that our products depend on need to be able to be linked together.

This creates a problem for us because PhysX was not designed with this use case in mind. Attempting to link against two versions of PhysX simultaneously would result in various naming conflicts or ODR violations.

When upgrading from PhysX 4 we solved this by

1. Changing our various uses of PhysX to be templated on the version of physx they depend on and branch their code accordingly
2. Modify the PhysX 3 and PhysX 4 libraries to not have any symbols in common

We're now faced with making the same changes again in PhysX 5 and I'm wishing I'd raised this issue when we upgraded to 4.

My request is that, going forward, my software would be able to link against two versions of PhysX without me having to make substantial code changes to the PhysX code. The specific changes that we've found need to be made are

• Renaming macros to include the version number
• Renaming the physx namespace to include the version number
• Renaming some global symbols to include the version number
• Moving some global symbols into anonymous namespace

I believe that this could be done less painfully on the PhysX side through the use of macros. I believe the existing use case that I'm sure others have of drop in replacement of PhysX versions (particularly minor updates) could still be achieved through the use of macros, namespace aliases, or minor redesign. I haven't tested either of these beliefs.

[amoravanszky]

Suffixing everything in the API with a version number would make the most common use case of upgrading a dependent code base that uses a subset of the API, a single version at a time, more difficult. That kind of update is usually very straight forward because with the current approach most of the dependent code doesn't change at all. We have historically always tried to prioritize ease of use for our least expert users so that one can "pay as you go" up in complexity, if you will, rather than hit a wall of complexity already when trying to evaluate the software.

For advanced applications like yours that require building against multiple PhysX / physics engines, the common pattern is to create a wrapper / abstraction layer that insulates your core engine from the physics library API completely. The best way to do this is to put this wrapper into a dynamic link library such that the all of the PhysX stuff not only ends up in its own compilation unit but its own executable which also gets around namespace but also CRT incompatibility problems.

You may want to look at PEEL as an example project that supports multiple versions of PhysX: https://github.com/Pierre-Terdiman/PEEL_PhysX_Edition/tree/main/PEEL

[shaneasd]

Thank you for your response. We did consider a wrapper layer and have used this approach for other libraries in the past where CRT incompatibility was an issue. We opted against it here because

• we estimated the cost (up-front at least) of creating a wrapper layer would exceed the cost of the necessary library modifications for our chosen approach.
• we wanted to avoid the implementation complications introduced by an abstraction layer (e.g. the two way mapping required to-from wrapper types).

On the whole I think I prefer our solution over your suggestion as I understand it. Examining the per-engine code in PEEL (thank you for the link. I was aware of its existence but hadn't considered the parallels with our problem) it looks like less work for us to modify the physx code than to implement the wrapper layer though it's hard to be certain.

Nonetheless. I'll keep your advice in mind for the next upgrade we do.