[triton-inference-server] new port

[Tim Paine (timkpaine)]

• Changes comply with the maintainer guide.
• The packaged project is mature and ready for broad sharing with vcpkg users
  • Has a release at least 6 months old or 6 months of demonstrated public development
  • Is an official component of something else meeting that criteria
  • Some other reason (please explain)
• The packaged project shows strong association with the chosen port name. Check this box if at least one of the following criteria is met:
  • The project is in Repology: https://repology.org/project//versions
  • The project is amongst the first web search results for "" or " C++". Include a screenshot of the search engine results in the PR.
  • The port name follows the 'GitHubOrg-GitHubRepo' form or equivalent Owner-Project form.
• Optional dependencies of the build are all controlled by the port. A dependency is controlled if it is declared an unconditional dependency in vcpkg.json, or explicitly disabled through patches or build system arguments such as CMAKE_DISABLE_FIND_PACKAGE_Xxx or VCPKG_LOCK_FIND_PACKAGE
• The versioning scheme in vcpkg.json matches what upstream says.
• The license declaration in vcpkg.json matches what upstream says.
• The installed as the "copyright" file matches what upstream says.
• The source code of the component installed comes from an authoritative source.
• The generated "usage text" is brief and accurate. See adding-usage for context. Don't add a usage file if the automatically generated usage is correct.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Exactly one version is added in each modified versions file.

[Jack·Boos·Yu (JackBoosY)]

Please give us the reason when you resolve the review suggestions.

[Jack·Boos·Yu (JackBoosY)]

Again, why we need to create several static libraries?

[Tim Paine (timkpaine)]

triton common’s three generated-code targets remain OBJECT libraries for upstream in-tree builds. Without installing their objects, CMake exports them as INTERFACE targets with no object paths, so installed Core/Server packages cannot link their protobuf/gRPC symbols. The three static wrappers package those existing objects separately because downstream uses each upstream target independently. This preserves upstream OBJECT-target behavior instead of converting them directly to STATIC.

[Jack·Boos·Yu (JackBoosY)]

I don't understand, after generating the OBJECT libraries upstream, don't they link them into the normal dynamic/static libraries? Or does the upstream export these OBJECT libraries directly for users to use?

Do you mean these OBJECT libraries are for use by other libraries in the same repository?

[Tim Paine (timkpaine)]

would you prefer to switch to installing the objects directly via OBJECTS DESTINATION?

[Tim Paine (timkpaine)]

I don't understand, after generating the OBJECT libraries upstream, don't they link them into the normal dynamic/static libraries? Or does the upstream export these OBJECT libraries directly for users to use?

Do you mean these OBJECT libraries are for use by other libraries in the same repository?

Yes. The source repo's OBJECT libraries are internal components reused across Client, Core, and Server in one combined CMake build.

vcpkg builds those as separate packages, so the objects disappear at the package boundary. Our static wrappers preserve them for Core and Server.

[Jack·Boos·Yu (JackBoosY)]

That make sense.

[Jack·Boos·Yu (JackBoosY)]

Also, why we need to remove -Werror here?

[Jack·Boos·Yu (JackBoosY)]

If -Werror already has in the source, we can keep it.