building static libs for ios/android
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Wed Mar 27 13:04:27 UTC 2024
On 2024-03-25 18:43, Johan Vos wrote:
> Hi Magnus,
>
> Thanks for your reply. I can indeed tell that there are major changes
> in upstream openjdk/jdk related to static builds, as the Skara ran
> into 3 conflicts over the past week while merging from upstream :)
> That is great news, and I'm glad the static build gets traction in
> openjdk/jdk.
Great! I look forward working with you to make sure we get a proper
solution in upstream that will fit your needs as well.
> This might be a good moment to work on the remaining android/ios
> specific clauses that are in openjdk/mobile but not (yet) in openjdk/jdk.
Unfortunately, that is a bit of a different story. :-( We tend to be
very reluctant of accepting ports to new platforms, unless we have
someone (basically, an organization or a company) backing up the port.
That means things like providing a CI system for the platform, making
sure there is engineering resources available in case there is trouble
with the platform in a future PR, committing to making the kind of
changes necessary if the platform evolves (virtual threads is a great
example of a highly complicated kind of change that might be needed),
and finally, helping remove the platform if it falls out of grace.
I don't know if you and/or Gluon might be able to provide what would be
needed. If you want to go down that route, we'd have to start a
discussion on porters-dev and involve Dalibor.
There are at least two points in favor in this case, though:
1) The changes required are fairly minimal. ios is basically macosx,
from the point of building, and android is basically linux. It's not
like porting to RISC-V where the entire C2 needs to be rewritten.
2) I saw that you have already created tests on GitHub action for these
ports. That means there is a simple way to make sure we keep the
functionality tested, at least build-wise. (Someone will still need to
run the tests on a regular basis, to make sure they don't break, though.)
/Magnus
> It is probably best to wait until you finished your current refactory
> of the static builds approach. I'll make sure the openjdk/mobile
> follows the new approach, so that the diff will be really small.
>
> I will probably merge my PR with the latest additional ios/Android
> changes into mobile/HEAD as that will make it easier to merge the
> incoming (openjdk/HEAD) changes with the latest changes for mobile.
>
> Thanks again,
>
> - Johan
>
> On Mon, Mar 25, 2024 at 3:31 PM Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com> wrote:
>
> On 2024-03-23 17:42, Johan Vos wrote:
>
> > Hi,
> >
> > I created a PR that brings in the remaining changes needed to
> compile
> > an image containing the static JDK libs (not the VM libs) for
> ios/android:
> > https://github.com/openjdk/mobile/pull/20
> >
> > As a major improvement, this PR also adds ios/android build scripts
> > for GA (thanks to Abhinay Agarwal for doing this). As a
> consequence,
> > we will immediately notice if an upstream commit (in
> openjdk/jdk) is
> > breaking the build for the mobile static libs.
> >
> > In a previous message, I suggested a separate branch would be my
> > preference for doing development work. However, there are 2 reasons
> > why I prefer this PR to go into the main branch:
> > 1. it seems I don't have permission to create new branches
> > 2. there is at least 1 major embarrassing bug in the current main
> > branch (fi instead of endif) hence an improvement sounds
> appropriate.
> >
> > Slightly related: the auto-merge operation by the skara bot had 2
> > merge conflicts recently, due to changes in the upstream make
> > directories. I fixed the conflicts, and while I didn't look in the
> > details yet, it seems Magnus is doing simplifications in
> openjdk/jdk
> > that are also simplifying some of the build logic for mobile.
> That is
> > great, thanks for that!
>
> <ominous music>More change is on the horizon. A storm is
> coming.</ominous music> Or maybe not. But things will happen in
> the area
> of static build. Hopefully good changes. :-) This is driven by the
> Hermetic Java project, which requires static builds of the entire JDK.
>
> I guess in the end this part of Hermetic Java is quite similar to the
> mobile project, but with the intention of bringing this to
> mainline. As
> a result of this wish, I wanted to make sure that static build is
> properly treated as a "first class citizen" in the build system.
>
> I was under the impression that the mobile project was more or less
> abandoned, but I'm happy to see this is not the case. I hope I can
> communicate with you so that we end up creating a single solution for
> producing static builds that are usable both for mobile and
> Hermetic Java.
>
> /Magnus
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/mobile-dev/attachments/20240327/02e2d9be/attachment-0001.htm>
More information about the mobile-dev
mailing list