VCPKG port for onnxruntime and modernize cmake builds

[ankurvdev]

Provider a vcpkg port for onnxruntime for easier builds and linking into external projects.

There's an initial effort made that can be used as a starting template for this
microsoft/vcpkg#14903
This port succeeds for x64-windows-static-md but none of the other standard triplets.

Overall the onnxruntime cmakelist.txt needs cleaning to support such a port in an efficient manner

• Allow for submodules to be optional
• Submodule binaries must be picked up using find_package, find_library
• Export standard cmake-config/cmake-target files for easier find_package(onnxruntime) support

[snnn]

Nice!

Also, I found finally they added versioning support. https://devblogs.microsoft.com/cppblog/take-control-of-your-vcpkg-dependencies-with-versioning-support/ That was really a blocking issue for us. If without it, Let's say if we put onnxruntime there, but later on protobuf gets a version that breaks onnxruntime build, what should we do? We can't publish a new release immediately just because Google protobuf did so. This was my main concern.

Allow for submodules to be optional

The biggest problem is how to handling ONNX. ONNX Runtime is not using a release version of ONNX. Can vcpkg accept such an ONNX package?

Submodule binaries must be picked up using find_package, find_library
If no submodule exists, that's fine. Otherwise, what if your system already installed protobuf, when you building onnxruntime which protobuf would be used , the one in submodule or the system installed one? It would be very confused.

Export standard cmake-config/cmake-target files for easier find_package(onnxruntime) support

Sorry I don't know how to do that. Welcome to contribute!

[roachsinai]

Hi, so for now find_package(onnxruntime) on windows is not supported?

[snnn]

Not yet. Welcome to contribute!

[chausner]

Let's say if we put onnxruntime there, but later on protobuf gets a version that breaks onnxruntime build, what should we do? We can't publish a new release immediately just because Google protobuf did so.

You are not required or expected to immediately publish a new version in this case. The vcpkg maintainers ensure that all packages stay compatible, so as part of updating protobuf, they will ensure that all dependent packages continue to work (and include patches for them to make them compatible, if needed).

[QiuYilin]

I tested luncliff's registry luncliff/vcpkg-registry , but encountered a similar problem with conan: conan-io/conan-center-index#17380 (comment) , luncliff/vcpkg-registry/issues/136#issuecomment-1851206111

[snnn]

Allow for submodules to be optional

For most build configs, it is done. A few of our build pipelines still need to use the submodules, for example, the webassembly pipeline needs to get emsdk from a submodule. I think it is not a big issue.

Submodule binaries must be picked up using find_package, find_library

Now all deps are fetch by cmake's FetchContent. So by default it works.

Export standard cmake-config/cmake-target files for easier find_package(onnxruntime) support

Done.

[loloxwg]

/Users/xwg/vcpkg/vcpkg/ports/onnxruntime: error: onnxruntime does not exist

onnxruntime is deleted?