Hello. On 07/15/2013 02:19 AM, Cedric BAIL wrote: > Hello, > > On Sat, Jul 13, 2013 at 3:43 AM, Rafael Antognolli <[email protected]> > wrote: >> Ecore.h already includes Ecore_Eo.h, so why do we need this extra > include? > > Indeed. Well, I know exactly why. E*_Eo.h API is unstable and will not > be a supported feature for 1.8. This is why you need to use a specific > flag to turn it on.
That should cover Rafael's question why I added it. Examples have been converted to use the EO api but the build system has not been changed to add the flag. Now I tried to find the problem with our nightly builds and just realized that some defines have been missing. A grep gave me Ecore_Eo.h as provider so I just thought they have been missing. > Example should not at this stage, I think, expose > any E*_Eo.h API as I don't think we want to encourage people to use > it. Why did the examples get then converted in the first place? Completely ignoring the fact they they never could have been even compile tested as the change was not done in the build system. > 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. regards Stefan Schmidt ------------------------------------------------------------------------------ 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
