[ gpsdrive ] OpenMoko (Openembedded) package for gpsdrive 2.10pre4

[Gernot Hillier]

Happy new year! :)

Joerg Ostertag (gpsdrive Munich/Germany) schrieb:
>> I'd like to share the results I reached up to now with you and ask for
>> review from your side before I try submitting the package to the
>> OpenMoko/OpenEmbedded people for inclusion into their mainstream. :)
> 
> This is really really welcome !!!

Great to hear. :)

>> The other one, gpsdrive-remove-hardcoded- 
>> paths.patch, does a quick'n'dirty fixup in the Makefiles removing
>> absolute paths. Are these statements still needed at all? Do you really
>> need to manually define -I/usr/include? If yes, any idea to fix it in a
>> sane way?
> 
> We are currently changing from automake to cmake. Maybe this eliminates the 
> problem. 

Oh, well. Let's hope it's not too complicated to get cmake controlled by
the OpenEmbedded build system - for the "nice" autotools it has some
presets making live much easier. But as I maintained a package with
autotools for some years, I'm quite sure I understand why you'd like to
change... ;-)

>> * As we're building for an embedded device where size *really* matters
>> (in the default OpenMoko load, we have about 7 MB of free space to
> 
> ...
> 
> Sounds reasonable. We'll have to think about how we can achive this the best 
> way. Since splitting the stuff on a desktop machine wouldn't make too much 
> sense.

For sure.

> We are currently thinking about splitting the map-icons package anyhow. You 
> probably have seen that in the svn. It already lost it's old Makefile.am 
> Files, more will follow. We will probably split this into one masterpackage 
> with the config FIles(icons.xml, osm.xml) and for each theme 
> (classic.ig.classic.small,square.big,square,small, ...) another package.

Well, as it looks that you're currently restructuring a lot of stuff, it
might make not too much sense to invest a lot of time in clever
packaging of the current state...

> The perl Stuff is normally only needed if you like to rearrange POIs of want 
> to download maps or want to setup database ...
> So this can surely be omitted.
> 
> The stuff in data/maps is a kind of basemap for desktop users to have 
> something to view at before they started to download additinal maps. SO you 
> can ommit these too.
> 
> You might have a look at the debian packaging i did. this can be found in the 
> debian/* directory in svn. This might be a good start for splitting into 
> different packages.

Thanks for all those hints. I'll try to come up with a suggestion based
on the current OpenEmbedded habits and your ideas soon. Probably it
won't be that detailed, though, as I learned that a lot is changing
right now...

>> * For interested parties (and well, to create a backup in the net ;) ),
>> I also attached the original bitbake recipe gpsdrive_2.10pre4.bb
>> (comparable to the RPM spec files or content of the debian/ directory in
>> the RPM/.deb world). Don't hesitate to ask me for explaining it if
>> you're interested in reviewing it in detail!!
> 
> Is there an easy way for me to cross-compile the openmoko package on my debian 
> machine? 

Depends on how you describe "easy" ;) It's a lengthy process as it
requires you to create a complete build of the whole OpenMoko
environment before you can cross-compile a package.

Lengthy is meant in terms of pure compile time, needed disk space and
dependencies on your system. To give you an impression: On my Ubuntu
desktop running on a 3 GHz Celeron Single-CPU, I had to install ~20
packages, the initial build tooks something like 5-10 hours and the
build directory eats up something like 5,5 GB.

However, the pure time to get everything in shape manually isn't that
long - something like 20 minutes or so, I'd say. If you wanna start
over, the easiest way should be to use the so-called MokoMakefile as
described on http://wiki.openmoko.org/wiki/MokoMakefile.

BTW: certainly, I can provide my current packages with installation
instructions at any time if there's someone out there wanting to try
them, so you don't need to do that by yourself...

> And is there an easy way to run the cross-compiled stuff in an emulator on my 
> debian machine?

No real idea, sorry. It looks like the environment created in the
procedure described above already contains some sort of qemu-based
emulation support, but I have not looked into this yet.

--
Gernot