On Fri, Feb 26, 2016 at 9:31 AM Carsten Haitzler <ras...@rasterman.com> wrote:
> On Wed, 24 Feb 2016 22:52:52 +0000 Mike Blumenkrantz > <michael.blumenkra...@gmail.com> said: > > > I am trying to avoid using the efl version defines because they don't > > indicate if it's the prerelease from git, meaning that the features > aren't > > usable until the release occurs; not very helpful if I want a feature to > be > > active now when it's supported. > > that's all we have. you can test to see if it works without the ifdef and > add > it back then and leave it until release... :/ > > > It seems like this should be something available; perhaps we need to > > #define EFL_VERSION_MICRO for it? > > that was never meant to be exposed because no new features were meant to be > exposed on micro versions - this is a temporary thing until next release. > exposing micro i think is possibly bad as it may encourage people to think > features can be added during micro versions. :) > I agree that this sort of check would be bad, but I think it's absolutely necessary to be able to identify development (git) versions of efl as belonging to the release which they eventually will become. Otherwise features will remain unused and untested until the release, at which point they will suddenly enable and probably trigger unexpected behaviors in some untested code path. I think the easiest way to do this would be that at the start of every development cycle we add a new define such as EFL_VERSION_1_18 which would continue to exist until 2.0 or whenever significant api breakage occurred. Then a new define could be added for each release and feature detection would work without enabling the adding of features into bugfix releases. > > > On Wed, Feb 24, 2016 at 5:49 PM Carsten Haitzler <ras...@rasterman.com> > > wrote: > > > > > On Wed, 24 Feb 2016 17:44:42 +0000 Mike Blumenkrantz > > > <michael.blumenkra...@gmail.com> said: > > > > > > > It's possible to #define constants in embryo, such as ones used for > > > version > > > > checking. I haven't found any reference for how to detect them in a > > > script, > > > > however. Any #if directive gets handled by epp during edje > compilation, > > > and > > > > using other statements involving the constant will result in compile > > > > failure due to undefined references. > > > > > > > > Is there any sample code for this in existence? > > > yeah... that's a problem. epp gets to the #... before embryo_cc ... so > > > there is > > > no way to do #if.... you CAN use defines from default.inc as they > expand > > > later > > > but you cant #if etc. ... the best way to do this is use > EFL_VERSION_MAJOR > > > and > > > EFL_VERSION_MINOR that are defined and know that efl is distributed > and > > > required to be "in step" so > > > > > > #if (EFL_VERSION_MAJOR >= 1) && (EFL_VERSION_MINOR >= 18) > > > ... > > > #endif > > > > > > for example :) > > > > > > -- > > > ------------- Codito, ergo sum - "I code, therefore I am" > -------------- > > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
