On Sun, 10 Feb 2013 22:52:19 +0100 Andreas Volz <li...@brachttal.net> said:
> Hello, > > In the EFL 1.7.5 I had options to disable threading support and > everything worked as it should. you know we stopped testing "phtread off" codepaths... and thats why efl now is pthread only :) that set of bull horns is going to have to be tackled. > The pthread version on Android misses some features from the Linux > variant. For now I just like to disable it complete and take time for > this task later. But it seems there's no option for it in trunk. yup. :) > Could you please tell me how to disable threading support as in 1.7.5? > Maybe even by hacking build environment. I played around, but some of > the m4 macros are really a nightmare! we removed the ability - we're threading only now. we're removing optional untested codepaths and reality is as we work more on things inside of evas and edje, we'll use threads more and more to parallelize things behind the scenes, so it's better to figure out how to make it work on bionic, than avoid it. > My feeling is that EFL trunk isn't as flexible as 1.7.5 regarding > configure options. I even get compilation problems in libraries that I correct. > never tried to compile with 1.7.5 (e.g. eeze or emotion) for Android. > The NEON detected also doesn't work for me (It worked with 1.7.5). I it will work if your CFLAGS have -mfpu=neon in them (ie u CAN compile neon code). :) > liked to idea of the separate libraries. But I'm sure there were good > reasons for the design change... years of complaints that efl is too hard to build (too many libs). too much overhead for releases (having to release 12+ libs each time and fix up versions/readmes/headers/whatever for each), and having to create layers and hoops to jump through - eg feature goes into evas - then we expose in ecore evas then expose again in elm.... - we make more and more apis and layers where reality is we just wanted the feature up in elm but it had to LIVE in evas. also this allows us to eventually inline across efl libs, gaining efficiency (eg make a libefl.so ... right now this is on the list of stuff for efl 2.0 possibilities). also now we need to be creating efl-wide interfaces (multiple-inheritance) and that just wouldnt fit into any specific lib in the old efl setup.. now with a single tree.. it is easy as its general efl infra stuff. > How ever - from some ones point who does a cross compiler platform port > it's a torture. But I don't like to cry... right now the efl tree is in bad shape for cross-compiling and even for general rebuilds. it's linking out-of-tree libs for example. it's not in good shape and need massaging into shape, but i have no time right now as i already have a backlog of like 200 mails (questions, patches etc. - like this mail of yours), and frankly my backlog is not shrinking... > Please help me. > > regards > Andreas > > -- > Technical Blog <http://andreasvolz.wordpress.com/> > > ------------------------------------------------------------------------------ > 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 > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel