Arg, I am so close. I can build the debug apk now with no errors, and it
seems okay, but when I try to install it on my phone it won't run (and
gives me no hint as to why)

Maybe something is failing, but the build keeps going instead of stopping.
I'll figure it out eventually.

> Great... maybe. Is this a good time to bring up emscripten nightly
builds? :)

I do think I would enjoy that. it would be nice to write a dockerfile that
doesn't rely on anything dreadfully out-of-date :D

Enough for today though, I need a break

On Mon, Dec 25, 2023 at 7:02 PM Ralph Versteegen <teeem...@gmail.com> wrote:

> Great... maybe. Is this a good time to bring up emscripten nightly builds?
> :)
>
> "Source option 5" means -source 1.5 meaning JDK 1.5 which is Java 5. My
> distro, Slackware, doesn't have an official JDK package (rather telling,
> since it includes toolchains for every other popular language) but there's
> a high profile 3rd-party one, openjdk-8u392.
>
> At https://developer.android.com/tools/releases/sdk-tools I found the
> notice:
> "...we are discontinuing an old way of updating artifacts for the SDK
> manager. ...we will no longer publish updates with this older XML format.
> Users of older versions of Android Studio, the old command-line SDK
> Manager, or the old SDK Manager UI will not receive updates to the SDK
> components via the SDK Manager"
> Also, in the notes for "SDK Tools, Revision 25.3.0 *(March 2017)", *it
> says that the "android" commandline tool and ant scripts have been removed.
> In "SDK Tools, Revision 26.0.0 *(March 2017)" *it says* "*tools/android
> now attempts to reproduce the functionality of android in tools prior to
> version 25.3.0 by invoking the new tools"
>
>
>
> On Tue, 26 Dec 2023 at 11:31, James Paige <b...@hamsterrepublic.com> wrote:
>
>> I have no idea how I managed to get platform version 31 installed in my
>> 2012 Android SDK *shrug*
>> I also ran into a "Source option 5 is no longer supported." openjdk8 was
>> the last java to support whatever "option 5" means. And Debian 9 was the
>> last debian to support openjdk8
>>
>> After a lot of messing around, I think I finally got the android nightly
>> building in a docker image (still using my cargo-cult artifact copy of the
>> android SDK)
>>
>> I'll push the Dockerfile for it. I ended up using Debian 11, but
>> installing an Amazon "corretto" backport of OpenJDK-8 and I /think/ it all
>> works. I managed to produce a debug apk a few minutes ago. If I can confirm
>> it actually installs and runs on my phone I'm going to update the nightly
>> build system to do it this way.
>>
>> > And I notice that block was modified in 4701548e0 ("SDL: switched build
>> system from Ant to Gradle") to make "android" optional. It's also used in
>> build/envsetup.sh but I don't remember ever running that.
>>
>> Aha, thanks! I'll check that out too.
>>
>>
>>
>> On Mon, Dec 25, 2023 at 4:56 PM Ralph Versteegen <teeem...@gmail.com>
>> wrote:
>>
>>> Well, you don't want the SDK that I have, because it no longer works!
>>> Running "android" (a binary from 2018) I get Android SDK Manager revision
>>> 25.2.5 which shows the most recent "SDK Platform" available for install
>>> being one for Android API 29 (Android 10). Which is the one I have
>>> installed. I had been meaning to install a newer SDK but had no idea that
>>> the SDK manager itself was no longer functional.
>>>
>>> Since you have targetSdkVersion set to 30, my SDK no longer works (it
>>> gets all the way through compiling and linking but fails in the final steps
>>> of packaging the .apk). I managed to create an .apk only by decreasing the
>>> target to 29 and changing my PATH to point to an older javac (javac from
>>> jdk-17.0.1 threw an error "Source option 5 is no longer supported. Use 7 or
>>> later." (about its "-source 1.5" argument), while javac 1.8.0 from
>>> openjdk-8u392 only printed a deprecation warning. Seems like Java has
>>> suffered a Perl 5/6-style fork)
>>>
>>> BTW when I try to edit  android:targetSdkVersion="30" in
>>> project/AndroidManifest[Template].xml it seems to have no effect. I finally
>>> figured out I have to edit project/project.properties too. That file claims
>>> to be autogenerated but is it? I couldn't figure out how to do so.
>>>
>>>
>>>
>>> On Tue, 26 Dec 2023 at 06:11, James Paige via Ohrrpgce <
>>> ohrrpgce@lists.motherhamster.org> wrote:
>>>
>>>> TMC, Question! What version of the Android SDK do you have installed?
>>>>
>>>> I think my version is probably from around 2012, and it is so old I
>>>> don't even know how to install it again (which makes it rough to create a
>>>> Docker image for it)
>>>>
>>>> I tried with the latest SDK, but it doesn't even have the "android"
>>>> binary anymore, it has "sdkmanager" instead with different command line
>>>> arguments, but our dusty old fork of sdl-android relies on "android"
>>>>
>>>> I'm hoping to find the oldest sdk that still works as a quick-fix, but
>>>> googling for "when did android SDK stop having android" doesn't work very
>>>> well :D
>>>>
>>>>
>>>>
>>>> On Thu, Dec 21, 2023 at 9:10 PM James Paige <b...@hamsterrepublic.com>
>>>> wrote:
>>>>
>>>>> Oh, I am pretty sure I know what is wrong. The nightly build vm for
>>>>> android is still Debian 9. It has scons version 2.3, which is still python
>>>>> 2.7 based. The latest scons on my Debian 11 box is 4.0
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Dec 19, 2023 at 9:13 PM James Paige <b...@hamsterrepublic.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Dec 16, 2023 at 7:40 PM Ralph Versteegen via Ohrrpgce <
>>>>>> ohrrpgce@lists.motherhamster.org> wrote:
>>>>>>
>>>>>>> That's strange... works on my machine. The error is:
>>>>>>>
>>>>>>> jni/../jni/application/ohrrpgce/tmp//filelayer.cpp:7:24: fatal
>>>>>>> error: fb/fb_stub.h: No such file or directory
>>>>>>>  #include "fb/fb_stub.h"
>>>>>>>                         ^
>>>>>>>
>>>>>>> And the reason for the error is that copy_source_actions() in
>>>>>>> ohrbuild.py isn't copying fb/fb_stub.h to android/tmp/ apparently 
>>>>>>> because
>>>>>>> node.get_implicit_deps(), which is meant to run a sconscript builtin 
>>>>>>> source
>>>>>>> scanner to return the list of headers isn't working. Try uncommenting 
>>>>>>> the
>>>>>>> two lines immediately below that:
>>>>>>>         def scstr(x): return ",".join(str(y) for y in x)
>>>>>>>         print("node", str(node), "sources", scstr(node.sources),
>>>>>>> "headers", scstr(headers))
>>>>>>> It should print:
>>>>>>> node filelayer.cpp sources  headers
>>>>>>> errorlog.h,fb/fb_stub.h,filelayer.hpp,lumpfile.h,mutex.hpp,config.h,miscc.h,fb/fb_array.h,fb/fb_config.h,fb/fb_device.h,fb/fb_error.h,fb/fb_file.h,fb/fb_string.h,fb/fb_thread.h,os.h,fb/fb_blackbox_config.h
>>>>>>>
>>>>>>
>>>>>> What it actually prints on the nightly build machine is:
>>>>>>
>>>>>> node filelayer.cpp sources  headers
>>>>>>
>>>>>> I haven't spotted why yet.
>>>>>>
>>>>>>
>>>>>>> As for .aab support... I had a look at upstream commandergenius.
>>>>>>> They seem to use gradle to create the .aab file, plus have a script for
>>>>>>> signing it. Gradle isn't used for just that. The addition of all the 
>>>>>>> gradle
>>>>>>> stuff is new since we forked. I don't know whether you want to copy or
>>>>>>> reuse the upstream work, requiring gradle, or completely reimplement
>>>>>>> support some other way.
>>>>>>>
>>>>>>> Trying to merge our fork with upstream commandergenius with "git
>>>>>>> merge" isn't going to work ("Your branch and 'origin/sdl_android' have
>>>>>>> diverged, and have 79 and 1915 different commits each, respectively" 
>>>>>>> which
>>>>>>> doesn't begin to describe the enormous patches and conflicts... I tried 
>>>>>>> git
>>>>>>> merge after which on the first conflict "git status" outputs 17972 lines
>>>>>>> and "git diff" 10588 lines of conflicts!). Manually merging it by
>>>>>>> cherry-picking or applying (some of) our commits on top of upstream 
>>>>>>> might
>>>>>>> be practical but is still tons of work. Cherry-picking their commits 
>>>>>>> which
>>>>>>> add .aab support is clearly far less work but isn't easy either, 
>>>>>>> because on
>>>>>>> top of the .aab signing commits (I couldn't easily figure out which 
>>>>>>> commits
>>>>>>> are needed but "git log --grep bundle" is a good start) you'd also need 
>>>>>>> all
>>>>>>> the ones for gradle support.
>>>>>>>
>>>>>>
>>>>>> First I'll dig around and see if there is a way to just change the
>>>>>> existing scripts to support aab format, which might be possible, I don't
>>>>>> know yet.
>>>>>> If not, I think trying to cherry-pick our commits on top of upstream
>>>>>> sounds like the least work, but I'll cross that bridge only if I don't 
>>>>>> find
>>>>>> any easier shortcuts.
>>>>>>
>>>>>> I'll keep you posted if I find anything.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Sat, 16 Dec 2023 at 01:49, James Paige via Ohrrpgce <
>>>>>>> ohrrpgce@lists.motherhamster.org> wrote:
>>>>>>>
>>>>>>>> I forgot to mention, the android builds have been broken for a
>>>>>>>> while (Since October 27)
>>>>>>>>
>>>>>>>> I haven't had time to narrow it down to the exact revision yet, but
>>>>>>>> I'll work on it when I have time.
>>>>>>>> I also want to work on the Android 12 fix, (I know what to do) and
>>>>>>>> the .aab format (Don't know what to do yet, but I'll figure it out
>>>>>>>> eventually)
>>>>>>>>
>>>>>>>> ---
>>>>>>>> James
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Ohrrpgce mailing list
>>>>>>>> ohrrpgce@lists.motherhamster.org
>>>>>>>>
>>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Ohrrpgce mailing list
>>>>>>> ohrrpgce@lists.motherhamster.org
>>>>>>>
>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>>>>
>>>>>> _______________________________________________
>>>> Ohrrpgce mailing list
>>>> ohrrpgce@lists.motherhamster.org
>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>
>>>
_______________________________________________
Ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org

Reply via email to