On 04/27/2014 08:02 AM, David Seikel wrote: > On Sun, 27 Apr 2014 07:54:35 +0300 Daniel Zaoui > <daniel.za...@samsung.com> wrote: > >> On 04/25/2014 01:25 PM, Jean-Philippe André wrote: >>> 2014-04-25 19:11 GMT+09:00 Cedric BAIL <cedric.b...@free.fr>: >>> >>>> Hello, >>>> >>>> On Fri, Apr 25, 2014 at 11:07 AM, Jean-Philippe André >>>> <j...@videolan.org> wrote: >>>>> 2014-04-25 17:49 GMT+09:00 Stefan Schmidt >>>>> <ste...@datenfreihafen.org>: >>>>>> Triggered from the Evas 3D commits I talked with jpeg about >>>>>> having a flag that controls if unstable API's are enabled or not. >>>>>> >>>>>> This would allow us to have big new features, I have Evas 3D in >>>>>> mind here, in the coe base but have it hidden behind an BETA API >>>>>> flag so we are not bound to stick with the API until we are >>>>>> happy with it. >>>>>> >>>>>> It should not be used to get all kind of crap into the code base >>>>>> though. I see it as a mechanism to give the code time to mature >>>>>> for one more release cycle. If we are happy with the API we will >>>>>> remove the BETA guards around it. On the other hand if we still >>>>>> are not happy with it after 3 months in the new cycle we can as >>>>>> well remove it from the master branch and give it more love >>>>>> before it will go in again. >>>>>> >>>>>> Jpeg was thinking about it for new functionaliyt of an existing >>>>>> API. I guess we could handle this as well. >>>>> I was thinking of my "filters" API which was hidden behing EO and >>>>> BETA flags for EFL 1.9. >>>>> But since we now actually use Eo with Eolian, the API itself is >>>>> auto-generated. >>>>> >>>>> So, we'd need Eolian to not generate some bindings for the legacy >>>>> API. Add a @beta flag or something in the EO file. >>>>> >>>>> Then, only the EO binding is generated, and the legacy API is not. >>>>> But I'm not sure if we can hide the symbols in the final library, >>>>> since >>>> EO >>>>> now uses real functions as entry points? >>>> Right now I do prefer that we do compile the code and require >>>> application that want to use it to explicitly require the flag. I >>>> see two reasons for it, first it prevent code rotting (obviously >>>> being compiled by everyone is better). Second it doesn't require a >>>> special package to try the beta API. Also for this release all Eo >>>> API is still in alpha with high risk of seeing its ABI and API >>>> broken for next release. It would means no binding at all for this >>>> release. So nobody will start playing with it. >>>> >>>> Also what would be the value of not compiling the code ? It will >>>> increase our code complexity and the chance to accidentally break >>>> something. >>>> >>>> Maybe I wasn't clear enough... I never mentionned not compiling >>>> the code. >>> Only disabling the API. >>> Apps that want to use it must #define EFL_BETA_API or something >>> like that to use it. And then they know it's unstable. >>> >>> Which basically means (now) it should only be part of EO APIs and >>> not in legacy headers. >>> >>> I agree with you that the code should always be compiled, quietly >>> tested, and if possible also used by core developers. >>> >>> Cheers, >>> >> You can also #ifdef ...BETA... inside the .h that includes the >> .eo.h/.legacy.h, e.g elm_gengrid.h. > Actually we already had EFL_BETA_API_SUPPORT.
I know. I meant around the legacy include, so you don't publish legacy APIs if you don't want. > > > > ------------------------------------------------------------------------------ > Start Your Social Network Today - Download eXo Platform > Build your Enterprise Intranet with eXo Platform Software > Java Based Open Source Intranet - Social, Extensible, Cloud Ready > Get Started Now And Turn Your Intranet Into A Collaboration Platform > http://p.sf.net/sfu/ExoPlatform > > > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------------ Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
