On Mon, 8 May 2023 19:45:18 GMT, Jiangli Zhou <[email protected]> wrote:
> > > All of that said, I think we can get away with a smaller subset of > > > targets and deliverables. AFAIK, graal needs the combined > > > `graal-builder-image` as input to their build anyway, so they should not > > > have any dependency on what the target `static-libs-image` produces. > > > Given that I propose the following behavior: > > > `make static-libs-image` produces `images/static-libs` with all .a > > > (including libjvm.a). `make static-libs-graal-image` produces > > > `images/static-libs-graal` with all .a except libjvm.a. `make > > > graal-builder-image` produces `images/graal-builder-image` like today, > > > but depends on and uses `static-libs-graal-image` instead of > > > `static-libs-image`. `make static-libs-bundles` depends on and uses > > > `static-libs-image` like today, so will contain libjvm.a, which is new > > > behavior. > > > > > > Sure, that should work too as long as there is a way to a) build the static > > libs only needed for graal some way b) keep `graal-builder-image` working > > as it does today. FWIW, we use `a)` at adoptium so as to be able to have a > > combination to build mandrel from. Not all users will want to have JDK + > > static libs so only the ones needing them should need to download them. > > Thanks @erikj79 @jerboaa. We can go with what @erikj79 suggested then. I'll > revise the PR. @erikj79 and @jerboaa please please review the updated version, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1540931243
