Re: [gpsd-dev] Describe your build environment, please?

[Samuel CUELLA]

On 9/5/14 1:11 PM, Eric S. Raymond wrote:
> I don't know what building software for Android is like, nor whether
> there are multiple ways to do it.  I want to say "we support Android" in
> build.txt, but not if it means someone is going to come back with
> "no, you only support a particular oddly non-standard way to do it".
>
> Please briefly describe your build chain and procedure.  Do you run
> scons and the compiler natively on Android itself or cross-compile?
> Is your method and toolset the one, or among several alternatives,
> that an Android dev would consider normal?  If there are several
> alternatives, what do we need to say in build.txt to clue devs and
> integrators into the one you're using?
I use the official google toolchain from the Android NDK (Native 
Development Kit). You can also use the toolchain from code sourcery I 
guess. I cross-compile from a "regular" (with GNU userland) linux box.
People who port software from linux to android tend to use either the 
NDK or code sourcery's.
If you are going to include "official" guidelines, I would go for 
recommanding the official toolchain from the NDK.
> What scons switches, if any, are required to build?
Here is what I use:

scons wordsize=32 snapshot=off arch=arm sample=shell

scons -j3 prefix=/usr libdir=$prefix/lib udevdir=/lib/udev chrpath=False 
gpsd_user=gpsd gpsd_group=uucp strip=False python=False bluez=0 
libgpsmm=0 clientdebug=0 dbus_export=0 ipv6=0 timing=0 ncurses=0 
ntpshm=0 pps=0 shm_export=0 socket_export=1 systemd=0 libQgpsmm=0 usb=0 
aivdm=0 ashtech=0 earthmate=0 evermore=0 fury=0 fv18=0 garmin=0 
garmintxt=0 geostar=0 gpsclock=0 itrax=0 mtk3301=0 navcom=0 nmea=1 
nmea2000=0 ntrip=0 oceanserver=0 oncore=0 rtcm104v2=0 rtcm104v3=0 sirf=1 
superstar2=0 tnt=0 tripmate=0 tsip=0 ubx=0 manbuild=0
With the following environment variables:

TOOL_HOME=/home/samuel/android-official-last/
export TOOL_PREFIX=${TOOL_HOME}/bin/arm-linux-androideabi
export CXX=$TOOL_PREFIX-g++
export AR=$TOOL_PREFIX-ar
export RANLIB=$TOOL_PREFIX-ranlib
export CC=$TOOL_PREFIX-gcc
export LD=$TOOL_PREFIX-ld

export CCFLAGS="-march=armv7-a -mtune=cortex-a8 -mfpu=vfp"
export ARM_TARGET_LIB=${TOOL_HOME}/sysroot

scons wordsize=32 snapshot=off arch=arm sample=shell

> Also, what startup configuration is required?  Do you use udev activation?
> What is the name of the GPS hardware device?
Here comes the tough part. I don't know if there is an udev equivalent 
on Android. I start the deamon from the init scripts with the device 
file it should work with.
I work with a G-Star IV USB device that works through a USB-to-serial 
bridge.
> I'm looking for whatever information an Android developer would need for
> going from a repo pull to a running GPSD.
In fact it's (far) more complicated than that. Android developers tend 
to be Java developers. Android (normally) provides GPS support through a 
well defined Java API.
The fun part begins when you want to add GPS support to an android 
device which doesn't have a GPS chipset onboard. It won't recognize it, 
because the official build from the vendor will lack support for GPS 
altogether. Rebuilding the exact same image with GPS support enabled 
would be very hard, and using alternative firmwares such as CyanogenMod 
will bring other problems (hardware not/malfunction) and is not 
guaranteed to make the GPS work.
The easyiest and least intrusive solution I found (after trying all of 
above, wasting a fair amount of time) is to directly run gpsd and have a 
piece of Java code that will listen to gpsd and act as a provider to 
other applications (A MockLocationProvider) through the standard API.