On Fri, 8 Mar 2024 17:36:33 GMT, Severin Gehwolf <sgehw...@openjdk.org> wrote:

>> That was modelled similar to `jdk_jlink` target. It also does the removal. 
>> When building with `--enable-runtime-link-image`, the flow is:
>> 
>> 
>> 1. Link the initial jdk image (current `images/jdk`). Output is 
>> $(RL_INTERMEDIATE_IMAGE_DIR)
>> 2. Generate the diff to the packaged modules (target `generate_jimage_diff`)
>> 3. Do the final link creating a runtime linkable jimage with 
>> `--create-linkabel-runtime` into `JDK_IMAGE_DIR`.
>> 
>> 
>> All three steps should have appropriate dependencies on each other. So I 
>> don't think there is a race. If you see one please let me know! Thanks.
>
> Why the rm? Because jlink refuses to run if the output dir already exists.

I don't see a race. The `rm` was there in the original code and is no scarier 
in the modified version. The jdk image is constructed by a combination of 
targets and recipes. The first one to run has to be jlink, then we overlay more 
stuff on top. If the makefile dependency resolution concludes that we need to 
rerun the jlink step, we clear out the directory completely to make sure we 
aren't leaving anything in there that's no longer valid. This is basically a 
precaution to guarantee a correct incremental build. It's not incurring a big 
build time penalty as jlink would have overwritten all files it would have 
created anyway. However, if a module was removed, or a file was removed from a 
module, the `rm` helps guarantee that we don't include such a removed file from 
a previous build attempt in the final image.

Or it may even be as Severin says, that jlink refuses to run, I don't remember.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1519686906

Reply via email to