On Fri, 21 Feb 2025 08:35:06 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
>
> Aleksey Shipilev has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Touch up comment

I'm not sure splitting static out into it's own task is the right long term 
direction we should be heading in. Magnus is working on reducing the duplicated 
work needed to build both a regular JDK and static libs at the same time, by 
reusing all the object files. 

I would also argue that there is a big difference between the old 
static-libs-bundle and the new static JDK distribution conceptually, so 
bunching them up in the same "static" category doesn't make much sense to me, 
other than as a (misguided) attempt at optimizing GHA compute resources. The 
old static-libs-bundle is static versions of JDK libs needed by certain 
downstream consumers of the regular JDK distribution (Graal). This is 
essentially an extension of the regular JDK. The new static JDK distro that 
@jianglizhou and @magicus are working on is a complete separate JDK variant 
that replaces the regular JDK.

Having one build task produce more than one JDK for testing can cause a 
challenge in the model for a build and test system, so for that reason it makes 
sense having a separate build task for the static JDK. That would also isolate 
build problems with the static JDK and avoid having them block test results for 
the regular JDK. I never delved deep enough into GHA to know if this would 
cause an issue here or not.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23715#issuecomment-2674635422

Reply via email to