On Tue, 27 Aug 2024 13:55:51 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Also update build to link properly > > And the discussion whether the checks are made "dynamically" or "statically" > is too simplified to be really helpful. > > Currently, we compile two sets of all object files, with slightly different > compiler arguments, one for dynamic libraries and one for static libraries. > Files that are doing things differently for these two modes have an #ifdef, > so the alternative way of doing things are not included in the object file. > > In your branch, you still have a separate compilation of all files for static > builds, but you also try to figure out through various means (which involves > jumping through some hoops to get the bootstrapping right) if this is a > static build or a dynamic build. In a way, one could argue that this is just > worse than the current solution, since you are still recompiling all files > separately for static libraries so you could "know" at build time if you are > static or not. > > What I am trying to do is to get to a point where we can compile almost all > files just once, and then have two trivially small files that are compiled > twice, with just a different value of a define that makes the difference. To > propagate this information to all other object files, they need to call the > function provided in this object file. So, is it then a "build time" lookup > or a "runtime lookup", or a "static lookup" vs "dynamic lookup"? The > semantics does not really matter. The whole point is that the difference in > build is reduced to an absolute minimum. Sure, this single "lookup" function > could be created more like the way you are doing in your branch to try to > figure this out without the help of the build system, but there is really no > point in that. This is a simple and elegant solution. @magicus please also specify contributor properly to so it's clear part of the change is based on/extracted from https://github.com/openjdk/leyden/tree/hermetic-java-runtime. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2313737779
