GNOME.org
 

Re: documentaion building for android

I've noticed that as well.
Obviously patches/pull-requests are welcome.

Thanks,
-Lionel

On 09/01/13 15:49, Dominique Bureau wrote:

BTW, for anyone trying to build this from Ubuntu (at least using 12.04 for
me), you will end up with some weird issues when trying to run the build-
clutter-android script. Ubuntu /bin/sh is a symlink to dash, and it would seem
that the script (or other components that it calls) would rely on sh-isms that
dash doesn't like.

I simply replaced /bin/sh to point to bash and it fixed the issues for me. Now
I'm stuck somewhere else ;)

--
Dominique

On Wednesday, December 19, 2012 08:15:19 AM Mike Rosset wrote:

Looks like the new git repo resolves some of the issues I had worked
around ie "trying to crossbuild jhbuild" , and some other issues I was
starting to tackle.
I had to fix an issue with libsoup, and I extended the README abit.
I'll put a pull request together.

Thanks for putting this together.

Mike

screenshot attached

On Wed, Dec 19, 2012 at 7:11 AM, Mike Rosset <mike rosset gmail com> wrote:

thanks Lionel

On Wed, Dec 19, 2012 at 3:56 AM, Lionel Landwerlin

<llandwerlin gmail com> wrote:

https://github.com/clutter-project/clutter-android is alive, feel free to
fork and send pull request if you find something wrong.


-Lionel

On 18/12/12 06:14, Mike Rosset wrote:

so far this is what I have. Im using a stand alone android ndk r8c.
and I'm building using ./configure --host=arm-linux-androideabi
--prefix=/data/data/local
prefix is probably not ideal but. this way I only have to build once
and I can make install, then just rsync /data/data/local over to my
android later.

for glib I set CFLAGS -I/data/data/local/include and LDFLAGS
-L/data/data/local/lib

libiconv builds and installs same with gettext.

build glib is another story, there are just to many runtime checks
done by autoconf.

based on http://developer.gnome.org/glib/2.34/glib-cross-compiling.html
this seems pretty normal, and its pretty typical to have to set some
ac_cv variables to by pass runtime checks. however in this case there
are quite a few.

what are you guys using currently to fix run times checks? is it
something I can use to reproduce a glib build or should I research
these autoconf vars and find the right values?

Regards,

Mike


On Mon, Dec 17, 2012 at 1:38 PM, Mike Rosset <mike rosset gmail com>
wrote:

Lionel that patch was as exactly what I needed . Ok looks like I have
what I need to start a README or something of sorts. If I have
problems I'll post to the list but I think with theses patches I'll be
ok.

On Mon, Dec 17, 2012 at 1:18 PM, Lionel Landwerlin
<llandwerlin gmail com> wrote:

Yes indeed the libiconv config.guess doesn't recognize the android
canonical host name.
This script is basically full of switch/case trying to match names like

theses :
| -mingw32* | -linux-gnu*

Basically what you need to do is add the -linux-android* to that, so you
can run the script.

You can find the packages we patched and the patches there :
http://vps10963.ovh.net/~djdeath/android-clutter/patches/
(Not all of the patches might be useful for you)

-Lionel


On 17/12/12 21:03, Mike Rosset wrote:

Thanks for the reply Lionel.

I forgot to mention that you probably need to use the following repos :

Few patches to glib to compile on Bionic :
https://github.com/djdeath/glib

Integration with the Android mainloop system :
https://github.com/dlespiau/glib-android

A few patches to cogl, most of them should be upstream now :
https://github.com/djdeath/cogl-android

Ok looks like I was on the right path here, but the distinction
between glib and glib-android had me a bit confused. thanks

I did run into a snag building both glib though. Related to libiconv
haveing an outdated config.guess. Looks like libiconv's git repos  is
using an outdated autoconf and friends so I'll play with that unless
you guys have a better work around?


How close is it from upstream? That's hard to say, because it might
require
a bit of time to investigate the remaining bugs.
Also the whole Android application life cycle and the mainloop
integration
don't really fit with the way we do things on more traditional GNU/Linux
systems...

Ironically the whole mainloop is exactly the reason I started playing
with clutter. Mainly because we have this exact same problem with go
language. Since go language can not produce share libs, there is
simply no way other then some IPC or RPC to use it in  some graphical
way with android. On the flip side if you want to build a command line
posix program for android with go. its pretty trivial.

Even though the mainloop is pita, I still think clutter in theory, is
one of the only open source alternatives that can probably get away
with using it.

As for things getting pushed upstream, I'm not to worried about that
as long as I know which repo's are which and that they are tracking
upstream.

Regards,

Mike
_______________________________________________
clutter-list mailing list
clutter-list gnome org
https://mail.gnome.org/mailman/listinfo/clutter-list



_______________________________________________
clutter-list mailing list
clutter-list gnome org
https://mail.gnome.org/mailman/listinfo/clutter-list

_______________________________________________
clutter-list mailing list
clutter-list gnome org
https://mail.gnome.org/mailman/listinfo/clutter-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]