You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The primary use case for this would be for Pothos modules implemented in a non-C++ language checking the version of the respective proxy environment.
For a specific example:
This came up with PothosNumPy needing to work around pothosware/PothosPython#18 until it was fixed in pothosware/PothosPython@1344396. It would be useful for PothosNumPy to be able to enforce that the installed PothosPython is of version 0.4.1 before attempting to build against it.
In this specific case, the version could be queried at runtime, leading to the workaround code path being executed if the version is early enough, but if, for example, a module depended on a specific feature being added, there is likely no way to test for this at runtime.
The text was updated successfully, but these errors were encountered:
The primary use case for this would be for Pothos modules implemented in a non-C++ language checking the version of the respective proxy environment.
For a specific example:
This came up with PothosNumPy needing to work around pothosware/PothosPython#18 until it was fixed in pothosware/PothosPython@1344396. It would be useful for PothosNumPy to be able to enforce that the installed PothosPython is of version 0.4.1 before attempting to build against it.
In this specific case, the version could be queried at runtime, leading to the workaround code path being executed if the version is early enough, but if, for example, a module depended on a specific feature being added, there is likely no way to test for this at runtime.
The text was updated successfully, but these errors were encountered: