On Thu, 20 Feb 2025 17:15:13 GMT, Aleksey Shipilev <sh...@openjdk.org> wrote:
> Noticed this when reviewing > [JDK-8349399](https://bugs.openjdk.org/browse/JDK-8349399), which had to > kludgy workaround the hunk introduced by `static-libs-bundles` addition > ([JDK-8337265](https://bugs.openjdk.org/browse/JDK-8337265)). I am somewhat > surprised we even have `static-libs-bundles` as additional target in what I > would consider a generic build-linux job! It looks cleaner to yank > `static-libs-bundles` into a separate build job. > > This effectively reverts parts of the original change, and does a few > modifications: > - I see no reason to store the bundles, and continuing to do so would > effectively overwrite `linux-x64-bundles` when we split the static build into > another job, breaking tests. Not sure why we had to publish those bundles, > @dougxc? They are not used in current JDK tests, I think? > - The matrix definition in `build-linux.xml` unconditionally includes > `debug` configuration to override flags and suffix, I had to redo this with > inline variables > > Named the new job `linux-x64-static`, since I expect @jianglizhou to slide > https://github.com/openjdk/jdk/pull/23471 just there by adding another > `make-target` into that job definition. > > I did a partial GHA run already, and I expect full run to complete without > errors. > > Testing: > - [x] GHA We are proactively ensuring Graal remains compatible with the OpenJDK master tip without requiring contributors to build libgraal. For example, we prepared [this Graal adaption patch](https://github.com/oracle/graal/pull/10562) to support your [DirectByteBuffers Cleaner work](https://github.com/openjdk/jdk/pull/22165). Removing static-lib-bundles would eliminate our canary tool's automation, significantly increasing manual effort. Please hold off on removing static-lib-bundles until we find a way into GHA. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23715#issuecomment-2672688231
