ADR for managing native libraries in GraalVM native images #43984
Conversation
There was a problem hiding this comment.
Thank you for the write down @cescoffier! It looks good to me. Just added a few comments that I leave up to you to decide if they are worth including or not.
|
Just realized - should we document pattern to use for when libraries have all binaries included in one artifacts vs using multiple classifers (multiple artifacts) ? |
I don't think we use any different pattern in this case (at least in native mode). |
I've added a note. |
This commit introduces an ADR detailing the process for managing native libraries in Quarkus extensions when performing native compilation with GraalVM. Key points include: - Using GraalVM's `Feature` mechanism to select and include platform-specific native libraries. - Centralizing native library management and runtime initialization configuration within the `Feature`. - Examples for implementing a `Feature` to include native libraries such as `brotli.so`. - Discussion of considered options and consequences of using the `Feature` approach. Co-authored-by: @zakkak
cescoffier
force-pushed
the
adr-binary-in-native-executable
branch
from
b6535c3
to
af6a5e8
Compare
gsmet
dismissed
maxandersen’s stale review
Comments have been addressed AFAICS. Let's merge!
|
AFAICS, Max was +1 and his comments were addressed so let's merge! |
This PR introduces an ADR detailing the process for managing native libraries in Quarkus extensions when performing native compilation with GraalVM.
Key points include:
Featuremechanism to select and include platform-specific native libraries.Feature.Featureto include native libraries such asbrotli.so.Featureapproach.