On Fri, Feb 8, 2013 at 10:41 AM, David Seikel <[email protected]> wrote:
> On Thu, 7 Feb 2013 23:18:59 +0100 Andreas Volz <[email protected]> > wrote: > > > Am Sat, 2 Feb 2013 23:56:02 +0100 schrieb Andreas Volz: > > > > > Hello together, > > > > > > I'm currently trying to port some EFL libs to android. > > > > Just like to report some success about this task. > > > > The EFL is working successful on android platform. Up to now I ported > > the buffer engine and use a native android bitmap to display rendered > > result. :-) > > > > As next task I like to polish it more and commit changes to SVN. I'll > > raw summarize my needed changes so anyone could add a comment before I > > start with this task. Please give me some comments. > > > > I won't provide any patches at the moment, because I used efl-1.7.5 > > and need to port it to trunk and I like to discuss them before. > > > > Library versions > > ---------------- > > Android doesn't well support the library versions (libxyz.so.1). Each > > application or library package is independent from others. So no need > > to use versions.I had to modify all Makefile.am to replace: > > > > "-version-info @version_info@ @release_info@" => "-avoid-version". > > > > Module structure > > ---------------- > > The app resources on android support only flat directory structure. So > > I had to change module structure > > > > /lib/evas/modules/engines/software_x11/linux-gnu-x86_64-1.7.99/module.so > > > > isn't possible. This goes together with next change... > > > > Module name > > ----------- > > For some reasons shared objects on android need to be named lib*.so to > > be correct included. Maybe this is also a limitation of the package > > creator. Don't know for sure. But for this reasons I decided to name > > modules like this: > > > > libevas_modules_engines_buffer.so > > libevas_modules_engines_software_generic.so > > > > (PS: if you are more experienced with android and teach me a better > > way to solve the library restrictions, please do so!) > > > > Module loader (evas) > > -------------------- > > I had to modify module loader evas-1.7.5/src/lib/file/evas_module.c to > > load modules from the new place in evas_module_paths_init(). In my > > case here local hacked to "/data/data/com.example.efl/lib/". The > > correct way would be for sure to get this path dynamic. Seems that > > this path is only available in the Java API. So I've to get it by JNI > > calls from Java. Other people out there do the same trick to solve > > this. > > > > I've to port evas_module_engine_list() for sure too. But until now I > > could survive without. > > > > The evas_module_find_type() needed changes too to support the new > > library paths. > > > > If I remember correct this were the biggest changes I've done until > > now. > > > > How to bring this into EFL trunk? > > --------------------------------- > > My idea to solve the build structure is to create a new configure > > option (e.g. --flat-lib-naming or more specific --enable-android) and > > handle the magic in all Makefile.am files with this options. I even > > think about auto detecting android support and just configure it in a > > correct way. This would be more smart. > > > > The change in evas itself are only several lines of code that I > > currently guard with #ifdef __ANDROID__. > > > > For sure all dependencies (libpng, libjpeg, freetype...) needs to be > > modified in some similar way regarding the library naming. I would > > maintain this as patches for release versions as long as they don't > > support android. > > > > Next steps > > ----------- > > Ok, after bringing android support with current state into EFL trunk I > > would start to write some software_android engine and later maybe some > > gl_android engine. I assume the input events (touchscreen) then needs > > also to be supported. I've really no idea how this works as I didn't > > care about it currently. But I'm sure there's a way... > > > > Help needed > > ----------- > > I like to commit my changes to EFL and afterwards I hope some > > tutorials and an example application could motivate someone > > experienced with writing evas engines to support this port. > > > > So if nobody complains after this email I'll commit my changes > > _carefully_ to EFL with being sure not to destroy any existing code. > > I'm looking forward to seeing your work. Dunno if I can help much, but > I'll certainly by trying it out. > Me too. I am a big fan of this task. I will try this later :) Btw, do you have any video recording that can be shared on youtube? This is very interesting. Thanks. Daniel Juyung Seo (SeoZ) > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. > > > ------------------------------------------------------------------------------ > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
