This partially simplifies the local native vec testing, more work to be done #137904
Conversation
|
Pinging @elastic/es-search-relevance (Team:Search Relevance) |
elasticsearchmachine
added
the
Team:Search Relevance
| } | ||
| } | ||
|
|
||
| tasks.register('buildSharedLibraryAndCopy') { |
There was a problem hiding this comment.
@mark-vieira is there a more canonical way to wire this for local building over to libs/native?
There was a problem hiding this comment.
The more idiomatic way would probably be to use composite builds here. If we configured this project to publish the zip as an artifact, configure it with the same maven coordinates as the binary artifact, then in theory we could just use --include-build libs/simdvec/native to get the same behavior.
There was a problem hiding this comment.
I don't know what composite builds are :/
My end goal is to provide simplified mechanisms not only for local testing but to unlock us writing up some buildkite jobs to build and benchmark native code changes (will be in subsequent PRs).
There was a problem hiding this comment.
If this unblocks you for now, seems fine to me. We can always improve this. @elastic/es-delivery should have some eyes on this though.
Co-authored-by: Rene Groeschke <[email protected]>
|
@breskeby think we can merge this as it is? Its just one step of many to get towards being able to run JMH over different architectures and compare against main/branch :) |
breskeby
left a comment
breskeby
left a comment
There was a problem hiding this comment.
lgtm for now. I'm with @mark-vieira we can always improve this later if required
5 participants
This changes the work flow a bit:
To build and copy, you simply need to do: