[Ohrrpgce] Android build
The android build VM was broken, but after I fixed it, looks like it is still having trouble compiling recently nightlyies ni/../jni/application/ohrrpgce/tmp//os_unix.c: In function 'dylib_noload': jni/../jni/application/ohrrpgce/tmp//os_unix.c:237:42: error: 'RTLD_NOLOAD' undeclared (first use in this function) void *ret = dlopen(libname, RTLD_LAZY | RTLD_NOLOAD); ^ jni/../jni/application/ohrrpgce/tmp//os_unix.c:237:42: note: each undeclared identifier is reported only once for each function it appears in /home/james/misc/android-ndk-r12b/build/core/build-binary.mk:472: recipe for target 'obj/local/armeabi/objs-debug/application/ohrrpgce/tmp//os_unix.o' failed make: *** [obj/local/armeabi/objs-debug/application/ohrrpgce/tmp//os_unix.o] Error 1 Failed to build Android apk for arch 32 ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] Android build breakage
It looks like one of the Surface related changes yesterday broke the Android build. My attempts to copy-paste the relevant error on my phone were met with frustration ;P See the cron mail ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] Android build problem
For the past week the Android build has been broken as a consequence of me finally checking in the change to increase minSdkVersion without alos installing the needed SDK package on the nightly build machine. However, when I went to fix that today I realized there is a new build failure on Android that happens first: jni/../jni/application/ohrrpgce/tmp/surface.cpp: In function 'int gfx_surfaceCreatePixelsView_SW(void*, int, int, int, SurfaceFormat, Surface**)': jni/../jni/application/ohrrpgce/tmp/surface.cpp:99:2: sorry, unimplemented: non-trivial designated initializers not supported make: *** [obj/local/armeabi/objs-debug/application/ohrrpgce/tmp/surface.o] Error 1 ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] Android build broken
Oh! I just noticed that the android build is broken. it fails with: jni/../jni/application/ohrrpgce/tmp//filelayer.cpp:702: error: undefined reference to 'embedded_files_table' collect2: error: ld returned 1 exit status /home/james/misc/android-ndk-r12b/build/core/build-binary.mk:677: recipe for target 'obj/local/armeabi/libapplication.so' failed make: *** [obj/local/armeabi/libapplication.so] Error 1 ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Android build
I found RTLD_NOLOAD in the headers for android-21 (Android 5.0) but not android-19, but I guess it's not available because of our low minSdkVersion. Anyway, it's not needed at all on Android so I got rid of it there. While that fixed the Android libapplication.so compile, I'm not actually able to produce an .apk for testing. I got an error that android-30 isn't supported by my SDK. I tried going back to a previous commit where we used android-29 and got a javac error that java 1.5 isn't supported anymore. Guess I need to upgrade. On Sat, 20 Aug 2022 at 01:15, James Paige via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > The android build VM was broken, but after I fixed it, looks like it is > still having trouble compiling recently nightlyies > > ni/../jni/application/ohrrpgce/tmp//os_unix.c: In function 'dylib_noload': > jni/../jni/application/ohrrpgce/tmp//os_unix.c:237:42: error: > 'RTLD_NOLOAD' undeclared (first use in this function) > void *ret = dlopen(libname, RTLD_LAZY | RTLD_NOLOAD); > ^ > jni/../jni/application/ohrrpgce/tmp//os_unix.c:237:42: note: each > undeclared identifier is reported only once for each function it appears in > /home/james/misc/android-ndk-r12b/build/core/build-binary.mk:472: recipe > for target > 'obj/local/armeabi/objs-debug/application/ohrrpgce/tmp//os_unix.o' failed > make: *** > [obj/local/armeabi/objs-debug/application/ohrrpgce/tmp//os_unix.o] Error 1 > Failed to build Android apk for arch 32 > ___ > 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] android build machine
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
Re: [Ohrrpgce] Android build breakage
On 26 September 2017 at 01:31, James Paige wrote: > It looks like one of the Surface related changes yesterday broke the > Android build. > > My attempts to copy-paste the relevant error on my phone were met with > frustration ;P > > See the cron mail > Odd, seems to be different behaviour in gcc, due to a different compiler version in the toolchain. I do see the same error. ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Android build problem
Oh, that's not hard to fix. But I notice that the versions of GCC used in the NDK versions you and I are using don't support C++11 designated initializer syntax; we use a GCC extension syntax instead. So it's not a C++11-compliant compiler, a nuisance. On Mon, 11 Mar 2019 at 07:15, James Paige wrote: > > For the past week the Android build has been broken as a consequence of me > finally checking in the change to increase minSdkVersion without alos > installing the needed SDK package on the nightly build machine. > > However, when I went to fix that today I realized there is a new build > failure on Android that happens first: > > jni/../jni/application/ohrrpgce/tmp/surface.cpp: In function 'int > gfx_surfaceCreatePixelsView_SW(void*, int, int, int, SurfaceFormat, > Surface**)': > jni/../jni/application/ohrrpgce/tmp/surface.cpp:99:2: sorry, unimplemented: > non-trivial designated initializers not supported > make: *** [obj/local/armeabi/objs-debug/application/ohrrpgce/tmp/surface.o] > Error 1 > ___ > 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
Re: [Ohrrpgce] Android build problem
Ah, I see. Is it worth us try to switch to a newer NDK? I also just noticed that the 64 but linux builds have been failing since last Wednesday. They say: slices.bas(1788) error 97: Ambiguous call to overloaded function, LARGE() in 'out_surf = surface_scale(in_surf, large(1, spr->w * .zoom), large(1, spr->h * .zoom))' scons: *** [build/game-slices.o] Error 1 On Monday, March 11, 2019, Ralph Versteegen wrote: > Oh, that's not hard to fix. > But I notice that the versions of GCC used in the NDK versions you and > I are using don't support C++11 designated initializer syntax; we use > a GCC extension syntax instead. So it's not a C++11-compliant > compiler, a nuisance. > > On Mon, 11 Mar 2019 at 07:15, James Paige wrote: > > > > For the past week the Android build has been broken as a consequence of > me finally checking in the change to increase minSdkVersion without alos > installing the needed SDK package on the nightly build machine. > > > > However, when I went to fix that today I realized there is a new build > failure on Android that happens first: > > > > jni/../jni/application/ohrrpgce/tmp/surface.cpp: In function 'int > gfx_surfaceCreatePixelsView_SW(void*, int, int, int, SurfaceFormat, > Surface**)': > > jni/../jni/application/ohrrpgce/tmp/surface.cpp:99:2: sorry, > unimplemented: non-trivial designated initializers not supported > > make: *** [obj/local/armeabi/objs-debug/application/ohrrpgce/tmp/surface.o] > Error 1 > > ___ > > 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
Re: [Ohrrpgce] Android build problem
I know that there were other reasons to use a newer NDK, but I don't remember what they are. I'm not bothered by it right now. A newer NDK would also increase our min supported Android version, I think? But I had to actually look up what it was (Android 2.3), because I'd forgotten. It wouldn't be bad if we had to bump the requirement slightly to Android 4.0.3 but I wouldn't want to go beyond that. That ambiguous call error is an odd one, it took me a few minutes to realise what it is. It's because integer constants are 64 bit in 64 bit builds, and converting an int64 to a double is a narrowing conversion - converting a double to an in64 is also a narrowing conversion (ie, potentially loses information). So the compiler isn't sure which way to go. On Mon, 11 Mar 2019 at 22:42, James Paige wrote: > > Ah, I see. Is it worth us try to switch to a newer NDK? > > I also just noticed that the 64 but linux builds have been failing since last > Wednesday. They say: > > slices.bas(1788) error 97: Ambiguous call to overloaded function, LARGE() in > 'out_surf = surface_scale(in_surf, large(1, spr->w * .zoom), large(1, spr->h > * .zoom))' > scons: *** [build/game-slices.o] Error 1 > > On Monday, March 11, 2019, Ralph Versteegen wrote: >> >> Oh, that's not hard to fix. >> But I notice that the versions of GCC used in the NDK versions you and >> I are using don't support C++11 designated initializer syntax; we use >> a GCC extension syntax instead. So it's not a C++11-compliant >> compiler, a nuisance. >> >> On Mon, 11 Mar 2019 at 07:15, James Paige wrote: >> > >> > For the past week the Android build has been broken as a consequence of me >> > finally checking in the change to increase minSdkVersion without alos >> > installing the needed SDK package on the nightly build machine. >> > >> > However, when I went to fix that today I realized there is a new build >> > failure on Android that happens first: >> > >> > jni/../jni/application/ohrrpgce/tmp/surface.cpp: In function 'int >> > gfx_surfaceCreatePixelsView_SW(void*, int, int, int, SurfaceFormat, >> > Surface**)': >> > jni/../jni/application/ohrrpgce/tmp/surface.cpp:99:2: sorry, >> > unimplemented: non-trivial designated initializers not supported >> > make: *** >> > [obj/local/armeabi/objs-debug/application/ohrrpgce/tmp/surface.o] Error 1 >> > ___ >> > 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
Re: [Ohrrpgce] Android build broken
Oops. Probably because datafiles.c is generate under build/ so doesn't get symlinked into android/tmp. On Sun, 31 Oct 2021 at 12:40, James Paige wrote: > > Oh! I just noticed that the android build is broken. it fails with: > > jni/../jni/application/ohrrpgce/tmp//filelayer.cpp:702: error: undefined > reference to 'embedded_files_table' > collect2: error: ld returned 1 exit status > /home/james/misc/android-ndk-r12b/build/core/build-binary.mk:677: recipe for > target 'obj/local/armeabi/libapplication.so' failed > make: *** [obj/local/armeabi/libapplication.so] Error 1 > ___ > 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
Re: [Ohrrpgce] android build machine
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
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.
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
Re: [Ohrrpgce] android build machine
On Sun, 17 Dec 2023 at 13:39, Ralph Versteegen 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
>
> 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,
>
Actually I didn't mean to claim that, it could easily be more work to
cherry-picking all their gradle+signing commits than to port our changes
upstream. Because at least we understand our own additions and have a hope
of reimplementing them in a hairy conflict.
> 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.
>
>
> 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
Re: [Ohrrpgce] android build machine
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
Re: [Ohrrpgce] android build machine
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 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
Re: [Ohrrpgce] android build machine
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 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
> 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
Re: [Ohrrpgce] android build machine
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
> 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
>> 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 s
Re: [Ohrrpgce] android build machine
What do you actually need the "android" binary for, aside from installing
the SDK? In build.sh I only see one use:
[ -e project/local.properties ] || {
android update project -p project || exit 1
rm -f project/src/Globals.java
}
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.
On Tue, 26 Dec 2023 at 10:55, Ralph Versteegen 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
>> 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
>>> 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
Re: [Ohrrpgce] android build machine
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 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
>> 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
>>> 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 al
Re: [Ohrrpgce] android build machine
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 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
> 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
>>> 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
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 "f
Re: [Ohrrpgce] android build machine
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 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 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
>> 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
Re: [Ohrrpgce] android build machine
Which Android does your phone have? 12+? Not running with no reason sounds
a lot like the problem that was reported in discord caused by the missing
section.
On Tue, 26 Dec 2023 at 13:42, James Paige wrote:
> 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
> 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
>> 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
>>> 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 a
