On Fri, 26 Feb 2016 16:04:32 +0000 Mike Blumenkrantz <michael.blumenkra...@gmail.com> said:
> 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. or maybe we should have another version field in configure.ac next to the efl version which is "api version" which we bump to 1.18 at the start of 1.18 dev and the efl version defines reflect this version instead? one solution in the past has been odd/even releases to denote development vs a real release. we have done v.0 -> v.99 to denote dev going to v+1. it means if people do git snapshots then apps wont think they have a real stable new 1.18 for example when what they have is some "work in progress" 1.17.99 and not everything is actually there and stable that would BE in 1.18. this would be the compromise by lying that it's 1.18 but keeping the actual package/efl version, .so version etc. still lower as at least some sign people can use that they could be encouraged to upgrade to a real release. > > > 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 > > > > -- ------------- 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
