[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Samuel CUELLA
Subject: Re: [gpsd-dev] Describe your build environment, please?
Date: Fri, 5 Sep 2014 21:33:52 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.1.1

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:

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]