Improve cross-platform compatibility #72
Merged
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
This change allows `openvino-finder` to find paths in newer released archives. For all versions since 2022.3.0 (checked: 2022.3.0, 2022.3.1, 2023.0.0, 2023.0.1, 2023.0.2, 2023.1.0), I see paths like: - linux: `runtime/lib/intel64/libopenvino.so` - windows: `runtime/bin/intel64/Release/openvino.dll` - macos: `runtime/lib/intel64/Release/libopenvino.dylib` This path-finding code is getting out of hand, though, so soon it will need to be pared down. For the time being, though, this enables finding more libraries and doesn't break any existing paths. One other caveat: this change does not yet find the Windows-linkable version of the library that Cargo expects for dynamic linking: `runtime/lib/intel64/Release/openvino.lib`.
OpenVINO can be configured with a `plugins.xml` file that points to libraries for running inferences on other devices. Previously, if this file was not provided and `openvino-finder` could not find it, the bindings crate would fail with an error. But this is not always necessary: if the plugin libraries are located in the same directory as the OpenVINO library, then a `plugins.xml` file is not needed. This is the case for APT-installed versions of the package, e.g. In these cases, we can pass an empty string to inform OpenVINO to look in the same directory as the main library ([example]). [example]: https://github.com/openvinotoolkit/openvino/blob/05a24b17769cb634f16343d551e25f542f0855b1/docs/snippets/ie_common.c#L14
This change completely refactors the "build and test" story for CI. With some unfortunate omissions (MacOS entirely, Windows dynamic linking), the bindings are checked against the last three versions of OpenVINO on more OS combinations. This is possible due to the new capabilities of the `install-openvino-action`, which downloads an OpenVINO archive and can now setup the runner environment. More work is needed, but this is a big step in the right direction. Because `install-openvino-action` is used more extensively, the previous "build and test" job using Docker is no longer needed. The Dockerfile is removed. Also, since the "build from source" option is not tested in CI, we avoid checking out all of OpenVINO's submodules, speeding up the build. Only a few C headers are necessary for the binding regeneration, IIRC.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
This change completely refactors the "build and test" story for CI and makes several tweaks to the
openvino-finderandopenvinocrates (see commit messages for details). The idea is to improve cross-platform compatibility; this is not completely fixed by this PR, but is certainly closer.