RFR: JDK-8232748: Build static versions of certain JDK libraries

[Johan Vos]

Op di 29 okt. 2019 om 14:11 schreef Bob Vandette <bob.vandette at oracle.com>:

>
> On Oct 29, 2019, at 8:44 AM, Magnus Ihse Bursie <
> magnus.ihse.bursie at oracle.com> wrote:
>
> On 2019-10-28 21:46, Erik Joelsson wrote:
>
> Certain downstream consumers of the JDK need to link to parts of it
> statically. To support this usecase, this patch adds a set of optional make
> targets that produce static native libraries for a selection of modules.
> These static libraries do not end up in the main JDK distribution but are
> instead packaged in a separate bundle that can be optionally overlayed on
> top of a JDK bundle. The new targets are only built when requested and are
> not added as dependencies on any existing target.
>
> Webrev: http://cr.openjdk.java.net/~erikj/8232748/webrev.01
>
> Looks good to me.
>
>
> +1
>
>
> Hopefully we can make a follow-up fix to remove the current "static libs"
> implementation that was needed by the Mobile project. This implementation
> was a bit hackish from the start, and it has bit-rotted severly, and might
> not even work right now.
>
>
> The current static build mostly works for a Mac build.  There’s only a one
> or two line change missing.
> This was done to validate https://openjdk.java.net/jeps/178 but we
> haven’t added a build/test to
> keep it from bit rotting.
>
>
> I'm eager to remove it, but I don't want to break the Mobile build, so
> hopefully we can find some way to adjust this new system to be usable by
> them, too.
>
>
> I’ve forwarded the RFR to Johan Vos to get his opinion on the new static
> lib mechanism.  I’m sure he has an opinion on the
> old static build deprecation.  I think he’d be more interested in getting
> iOS and Android build changes that using the old
> static build support once this change gets integrated.
>

True. Actually, my main goal is to stay as close as possible to the OpenJDK
master. Redoing the static changes for Mobile won't be a major issue, so I
prefer having the best approach in OpenJDK (as in the current webrev) and
we can then work on fixing what is broken on mobile. If the mobile changes
can get upstreamed to openjdk, that would be ideal. Otherwise, we can
upstream them to https://github.com/openjdk/mobile (which is auto-synced
from openjdk/jdk).

- Johan