build: tritonfrontend support for no/partial endpoint builds
#7605
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| target_link_libraries( | ||
| py-bindings | ||
| PUBLIC | ||
| ${OPENTELEMETRY_CPP_LIBRARIES} |
There was a problem hiding this comment.
Now that these libs are exposed publicly by the tracing-library that is already linked to the py-bindings target, do we need to do it again here?
There was a problem hiding this comment.
Without linking and including these libraries/directories to py-bindings, the build fail which points to the src/CMakeLists.txt linking change from PRIVATE to PUBLIC not having the intended consequence. Hence, will revert the src/CMakeLists.txt level changes and keep these link/include operations.
There was a problem hiding this comment.
But how can maintarget don't need handling like this? Isn't main and py-bindings conceptually the same in terms of compilation and linking?
There was a problem hiding this comment.
Thank you for the suggestion. The new handling of tracing-library requires only linking py-bindings to tracing-library without including/linking any opentelemetry directories or libraries directly to py-bindings.
The fix was to link tracing-library "as is" and not link $<TARGET_OBJECTS:tracing-library> because linking the latter will not propagate the link interface of tracing-library when linked with the final library.
rmccorm4
changed the title
tritonfrontend support for no/partial endpoint buildstritonfrontend support for no/partial endpoint builds
| @@ -96,13 +94,10 @@ endif() | |||
|
|
|||
| if(${TRITON_ENABLE_TRACING}) | |||
| message("TRACING/STATS IS CURRENTLY NOT SUPPORTED.") | |||
There was a problem hiding this comment.
I don't understand this part, if not supported, then why introducing the dependency?
There was a problem hiding this comment.
Currently, when building through build.py or cmake, tracing can be enabled in the build. From my understanding, this means that tracing-library (tracer.h) will get built with the #ifdef TRITON_ENABLE_TRACING sections included. Hence, when http-endpoint-library or grpc-endpoint-library include tracer.h (here and here) it will look for the tracing dependencies that tracer.h requires.
There was a problem hiding this comment.
There was a problem hiding this comment.
I think this would be a good change. Currently instead of linking the tracing-library, we do something along the lines of:
http_server.h
...
#include "tracer.h"
...and in CMakeList.txt to handle the dependencies we do:
target_include_directories(
http-endpoint-library
PRIVATE ${OPENTELEMETRY_CPP_INCLUDE_DIRS}
)But now that we are changing the tracing-library links/includes to be public, I replaced:
target_include_directories(
main/http-endpoint-library/grpc-endpoint-library
PRIVATE
${OPENTELEMETRY_CPP_INCLUDE_DIRS})with this:
target_link_libraries(
main/http-endpoint-library/grpc-endpoint-library
PRIVATE
tracing-library)There was a problem hiding this comment.
With assistance from @fpetrini15, I was able to verify that these changes work with the windows build as well.
CI Pipeline ID: 19374177
What does the PR do?
Currently, for the
tritonfrontendpython package only works for builds where all the supported endpoints are enabled. And for builds with partial endpoints enabled, the building of thetritonfrontendwheel is skipped.This PR is meant to add support for partial endpoint builds for
tritonfrontend. With these changes,tritonfrontendwheel will build in all cases and match the functionality of thetritonserverbinary.Checklist
<commit_type>: <Title>Commit Type:
Check the conventional commit type
box here and add the label to the github PR.
Where should the reviewer start?
src/python/tritonfrontend/_c/tritonfrontend_pybind.ccrestricts portions of C++ code that is binded.src/python/tritonfrontend/_api/__init__.pyrestricts which python apis are included in the tritonfrontend wheel.build.pychanges allow for wheel to be tested in CITest plan:
Added testing for
tritonfrontendto variant builds test.