Re: Current status of Ada development for an Android target ?

[Lucretia <laguest9000@googlemail.com>]

On Monday, 13 June 2016 00:36:19 UTC+1, Simon Clubley  wrote:
 
> What's going on here is that I'm working on a personal project which
> has a range of libraries and other code associated with it. I can see
> myself reusing various parts of it on a range of targets in the future
> including Android NDK applications.

Well, armv7-a/neon builds fine. mipsel doesn't failing because of a missing variable:

/home/laguest/src/mine/free-ada/tmp/android-mips/gcc/./gcc/xgcc -B/home/laguest/src/mine/free-ada/tmp/android-mips/gcc/./gcc/ -B/home/laguest/opt/test-android-gcc/mipsel-linux-androideabi/bin/ -B/home/laguest/opt/test-android-gcc/mipsel-linux-androideabi/lib/ -isystem /home/laguest/opt/test-android-gcc/mipsel-linux-androideabi/include -isystem /home/laguest/opt/test-android-gcc/mipsel-linux-androideabi/sys-include    -c -g -O2   -W -Wall -gnatpg -nostdinc   g-soccon.ads -o g-soccon.o
g-socket.ads:436:55: "MAX_tv_sec" not declared in "OS_Constants"
g-socket.ads:1171:58: "SIZEOF_fd_set" not declared in "OS_Constants"
../gcc-interface/Makefile:310: recipe for target 'g-soccon.o' failed


Looking at the source code, I can't see how it's not being defined:

/**
 ** On Solaris, field tv_sec in struct timeval has an undocumented
 ** hard-wired limit of 100 million.
 ** On IA64 HP-UX the limit is 2**31 - 1.
 **/
#if defined (sun)
# define MAX_tv_sec "100_000_000"

#elif defined (__hpux__)
# define MAX_tv_sec "16#7fffffff#"

#else
# define MAX_tv_sec "2 ** (SIZEOF_tv_sec * 8 - 1) - 1"
#endif
CNS(MAX_tv_sec, "")
}

(from s-oscons-tmplt.c)

 
> For that reason I originally started writing it in pure C, but even
> with some libraries I've written (such as a safer string library)
> the C code is taking too long to write and there's way too much
> boilerplate code and low level handling of things going on.
> 
> Given a good range of unknown future targets the next best logical
> option for portability is to use C++ but my heart _really_ wants to
> use Ada now that I've accepted I need to use a higher level language
> for this project.

I know what you mean.
 
> As such I am having a serious think about the Ada compiler situation
> as it relates to the viability of Ada for various targets. BTW, I also
> see the DragonEgg project is still dead (the frontend is still stalled
> at LLVM 3.3 and gcc 4.6 for Ada; I really wish LLVM had a native Ada
> front end so you could use the full range of LLVM targets.)

This is a major problem atm, both Google and Apple have deprecated GCC, I can see this happening more and more and LLVM doesn't have an Ada compiler. Getting GNAT onto LLVM would automatically open up these targets.

Luke.