RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v18]

[Erik Joelsson]

On Fri, 8 Mar 2024 17:36:33 GMT, Severin Gehwolf <sgehwolf at 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