Revert "efl: disable backtrace for release too."

Desktop / Enlightenment / EFL Core Libraries - Carsten Haitzler (Rasterman) [rasterman.com] - 17 November 2016 03:41 EST

This reverts commit dc7806e6856b584b387b0126f994e461f7c897cf.

NO. python does it out6 of the box by default. fix the error if you have one and stop just "turning off the noise". the point of having this is so that a REAL "why" can be provided by a user by putting it through eina_btlog and you can see HOW the error happened at least as a backtrace. turning it off "unless you sety environment
vars" is STUPID. especially for users of e who will likely be unable to do this a they jusr use a display manager to launch e and cant just "change environment vars" because they dont know how. you have just made things worse for getting information fromt he people LEAST capable of providing information which is where we need automated ways of doing this "the most".

i use this backtrace all the time. every week or so i identify an issue just by this built in trace so i know HOW we called that func because the err complaint was utterly useless as it didnt tell me the caller etc. which i needed to know "why". this also solves a valid complain that if you are developibng with efl and e.g. use a legacy func and pass in an invalid ob you need to know what CALLED the legacy func. often the issue is several levels up. its the silent masses who appreciate the feature and use it or then DONT complain. this allows them to know what the SOURCE of the error is and notjust where it ends up and this should be done by default out of the box regardless of it being long because providing more informations is always better than less. do you propose that kernel oopses should cease dumping all registers and half a screen worth of junk because "well just set a kernel boot param to turn it on next time". no. go propose that python turn off their backtraces by default unless you set and env var. get these groups to agree to do this, then i'll believe you that this is TRULYU annoying and not useful and should be off.

you do this just because a few peolpe complain about an error happening that "SHOULD NOT BE THERE". then FIX THE ERROR. the bt if provided should nicely provde complete info on how you got there. just making the error a 1 liner (and those lines are super long and for me 90% of the time wrap 2 or 3 lines in a terminal) is just sticking your head in the sand. if its not an error then dont use an eina ERROR use debug or warn or something else...

###

diff --git a/configure.ac b/configure.ac
index ca58fff..6ebb2c9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -85,7 +85,13 @@ case "${build_profile}" in
esac

prefer_assert="no"
-eina_log_backtrace="no"
+eina_log_backtrace="yes"
+case "${build_profile}" in
+ dev|debug)
+ prefer_assert="yes"
+ eina_log_backtrace="no"
+ ;;
+esac

# Enable CRI & ERR backtrace by default for release but not for dev/debug
AC_DEFINE_IF([EINA_LOG_BACKTRACE_ENABLE], [test "x${eina_log_backtrace}" = "xyes"], [1], [Default log level triggering backtraces])

56fd30f Revert "efl: disable backtrace for release too."
configure.ac | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

Upstream: git.enlightenment.org


  • Share