Yop, On Mon, Jul 15, 2013 at 11:12 PM, Stefan Schmidt <[email protected]> wrote: > On 07/15/2013 01:34 PM, Stefan Schmidt wrote: >> On 07/15/2013 02:19 AM, Cedric BAIL wrote: >> >>> I would be more for disabling the build of this example at this stage. >> >> Instead of disabling example they should just get reverted to the state >> before the eo api change and kept working like this. > > I did a bit of digging on this. > > Reverting my patch breaks make examples like this: > ecore_idler_example.c:109:17: error: ‘ECORE_IDLER_CLASS’ undeclared > (first use in this function) > > The usage of ECORE_IDLER_CLASS is like this since the efl merge. Means > before any change of the Eo headers coming in. > > Which in turn makes this a regression in the API we are offering. An > application that might used that with 1.7 would not longer be able to > use it with 1.8. Well, it could enable the flag to get the Eo api but > that is something we don't want.
The merge with eo started before the single tree merge. ECORE_IDLER_CLASS is provided by Ecore_Eo.h and does only exist in 1.8. It is just impossible it comes from 1.7, Eo didn't exist at that times. I have no idea where the example come from and I couldn't dig a version that come from before the merge. That's why I proposed to disable it for now. -- Cedric BAIL ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
