[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:
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.