On Mon, 11 Aug 2025 14:18:41 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
>> Hm. I put it there since it was the only place where we could be sure we >> know *all* launchers for a module. I could have each launcher add itself to >> the list, but then I either need to check if it is already there, or we will >> just append to the list each time we rebuild. And we risk a race when >> several launchers build at the same time. > > I could also create a separate file for each launcher with a name pattern and > gather up all these files in StaticLibs.gmk, but then I will get problems > with left-over such files, for e.g. if incrementally building after removing > a launcher. Not a common scenario, I agree, but it seems like a worse > solution. This solution was modeled on how we create `module-included-libs.txt`. I agree that it is a bit hacky to inject this kind of stuff in ModuleWrapper, but I can't see how we can do it more cleanly. That's the only point at which we know the entire module for a phase. Maybe we can improve optics by doing a more official-looking "hook" for injecting functionality at pre-/post- whole-module processing? That would keep ModuleWrapper slimmer and without all the current specialized hooks, and make the name "wrapper" more relevant. Or, we could rename the makefile to indicate better that it does a lot more than just wraps a file. (I have no good suggestions right now.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2266936847
