On Wed, 18 Aug 2010 21:42:12 +0200 Albin Tonnerre <albin.tonne...@gmail.com> said:
> > On Wed, 18 Aug 2010, Tom Hacohen wrote: > > > > > On Wed, Aug 18, 2010 at 10:27 PM, Vincent Torri <vto...@univ-evry.fr> > > > wrote: > > > > > >> EFL_COMPILER_FLAG([-Wall]) adds -Wall to CFLAGS > > >> > > >> m4_ifdef([v_mic] ***) checks if v_mic is used (that is if the micro > > >> version of eina is defined. I did that in order to add these flags only > > >> when in "developper mode" (not in release mode) > > >> > > >> But you can use EFL_COMPILER_FLAG without m4_ifdef. Just like that: > > >> > > >> EFL_COMPILER_FLAG([-Wall]) > > >> > > > > > > > > > Cool. Is there a standard way to choose between developer mode to release > > > mode in autotools? (except for what you did with the versions) > > > Maybe we should consider adding that as well. > > > > better ask raster, as i'm not sure exactly which part of the version is > > not used for the release mode > > IIRC, v_mic is always used. The "development" part is v_rev - the current SVN > revision, which is m4_undefine'd for releases. from efl 1.0.0 on (well eet 1.4.0 too - eet is a stupid exception here, but maybe over time it will come into line). v_rev is indeed off for release. it's off now in svn. v_rev is on otheriwse when back in "normal dev mode". v_mic is for "bugfix releases". ie after 1.0.0, 1.0.1 will simply be a patchlevel fixing bugs, maybe optimising some internals, cleaning something up. no features are added. nothing new. just "stuff fixed/improved silently" as far as any app/lib is concerned that uses EFL. when v_mic goes up - we did a new release with fixes. v_min is for "major major bugfix(es)" but mostly for "hey - we added new features". new api calls. new enums. new struct members, new code-path options that were not meant to work before, but now do etc. etc. - when this goes up, v_mic goes back to 0 and we have improved that lib with new stuff or very significant fixes. the lib will not break for existing apps/libs, BUT new libs/apps cannot work with an older minor versioned lib - eg an app built for 1.2 cannot 100% be guaranteed to work with 1.1 - but 1.2.3 will work with 1.2.1, so its backwards-compat for older built apps and libs only. v_maj is major release version. as of now it's. if this goes up - we broke api or abi. we'd damned well never break this unless we ABSOLUTELY HAVE TO. i'd like to have at least a few years between now and any break. every break pisses developers who use api's off. as for forcing -W's into builds. no. this is compiler dependent AND it's the task of CFLAGS. you can make this happen for you NOW. export CFLAGS="-W -Wall -Wextra -Werror" etc. done. nothing to be changed anywhere in any svn in any source tree. by putting it on there you force error output for those that simply dont want it OR don't care and wont read it anyway, or it simply confuses them. we have enough gentoo users who are unable to read as it is. (sorry - have to say that, but it's true - there are enough who simply paste compiler output just so we can become reading services. SIMPLE errors like "blah.h not found" and having to tell them "well blah.h is not found. maybe you need blah?"). haven't you seen enough pasts of "but when e starts, it logs errors about this hash being null,. that must be the bug why it segv's" without ever using gdb. because something prints out "warning" to people who have no idea what the waninng actually means, it sends them off on a vector wasting their and our time. other than that, -W's are the job of your CFLAGS and you can, if you want them and to fix wanrings, set it up in your bashrc or have an alias that changes your cflags to add them in etc. etc. eg: alias cflagwarn='export CFLAGS=$CFLAGS" -W -Wall -Wextra -Werror"' then just: cflagswarn before doing efl compiles. setting warning flags simply does not belong in the makefiles, configure scripts etc. of a project. if you say "well lets make it a --enable-warnings" then just SET YOUR CFLAGS instead! there is no point in involving configure. this does not mean i hate the warnings and discourage them in general - it just is not the place for them to be set on by default in configure scripts. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
