[gst-devel] GStreamer on android [Fwd: Re: GIT repositories]

[Edward Hervey]

On Fri, 2009-03-13 at 20:57 +0100, Farkas Levente wrote:
> Edward Hervey wrote:
> > I thought I'd also send this mail out for anybody interested in building
> > GStreamer on android easily with git repositories.
> > 
> >   These repositories only contain, so far, the patches that were on the
> > google groups site. I splitted them up into individual commits, in order
> > to make it easier to push upstream what can be pushed upstream and leave
> > alone what can't be pushed upstream.
> 
> what's the reason why something can't be pushed upstream?
> 

* intrusive patches that need cleaner rewrites.
  For example : There's not i18n/libiconv/gettext on Android. Therefore
we need to deactivate that everywhere in the modules we're using
(glib/liboil/gst*).. but currently it uses non-standard #ifdef ANDROID.
We should transform that into a clean way to disable i18n support for
all those modules.

* Android specific defaults.
  For example : We can use fbdevsink on the G1... but the default sink
isn't the same as on unix. We could split that up in one upstream patch
that makes it more modular to compile in a different default, and one
patch (a one-liner non-upstream patch) that defines the default fb
device on android.


* Android-specific Makefiles and auto-generated files
  Android doesn't use the standard autotools build system, but has it's
own build system. That means that we have to store files that are
normally generated at configure time (config.h, *.in) or compile time
(*-enum.[ch], gst parser (uses flex/bison), ...) and have Android.mk
makefiles in all the correct directories.
  This is in fact a similar issue that was Zaheer has with the S60 port,
and very close to what we do for the win32 builds.
  We need to find a clean/unified way to solve this for all
non-autotools build systems/architectures. One could be switching away
from autotools and using CMake (which can create Makefiles for various
systems).

  Edward