i was comparing the bindir results of aurtofoo vs meson and some
things were missing/poking out at me. this makes them be in sync -
install the ewl_wl+test obnaries, ensure to chmod +x+r etc. scritps
AND install them
a new shiny buildtool that currently completes in the total of ~ 4 min..
1 min. conf time
2:30 min. build time
Where autotools takes:
1:50 min. conf time
3:40 min. build time.
meson was taken because it went quite good for enlightenment, and is a traction gaining system that is also used by other mayor projects. Additionally, the DSL that is defined my meson makes the configuration of the builds a lot easier to read.
Further informations can be gathered from the README.meson
Right now, bindings & windows support are missing.
It is highly recommented to use meson 0.48 due to optimizations in meson
that reduced the time the meson call would need.
Co-authored-by: Mike Blumenkrantz <zmike@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7012
Depends on D7011
As usual with our code, EFL_RUN_IN_TREE=1 will lead to usage of
binaries from the current build dir instead of system.
To make user life easier, add -l/--lifecycle-debug and
-L/--lifecycle-no-debug options, as well as -h/--help. The
lifecycle-debug option will export the correct environment variables,
such as EO_LIFECYCLE_DEBUG, EO_LIFECYCLE_NO_DEBUG and
EINA_LOG_LEVELS=eo_lifecycle:4 if no such level was set for that
domain.
Last but not least, pass all command's stderr thru eina_btlog so
backtraces are automatically translated to function names, files and
lines. This one was a bit trickier to respect colors and stdout/stderr
contents, see comments in the script.
This has been in the making for a very long time. Thanks to Marcel for
reminding me to do it.
What is it?
This is a tool to help application developers debug their apps with
everything Eo. Eo is strict, but not as strict as it can be. Many strict
tests and debug are very expensive to implement, and we have so many
hot-paths that even basic "ifs" to check if debugging is enabled will
add significant overhead to normal running applications. This is why I
created this library. All the expensive tests and bookkeeping should be
wrapped around with "#ifdef EO_DEBUG". With this change, libeo.so is
compiled twice, once normally, and once with this define set (as
libeo_dbg.so). This means that normal eo code will not be affected, but
if you decide to debug your application, all you need to do is:
LD_PRELOAD=/path/to/libeo_dbg.so ./app
Or use the convenient wrapper:
eo_debug ./app
Which will load the debug heavy version.
What's currently there: at the moment, EO_DEBUG enables xref and
data_xref and stricter tests when fetching object data.
In the future, I also plan introducing "zombie objects", which
essentially mean that objects are never really deleted, so you can query
them long after they are gone to get more information on what they were.
So if for example you have an object id that you want to query after the
object has been deleted, you can.
I also plan on having a way to disable/enable certain debug mode
features via env vars, and maybe make the test suite link against this
one instead of the normal one, and possibly add more internal hooks for
the test suite to better inspect internal state?
P.S: The amount of errors spewed out when running it on elementary_test
makes me wish I wrote this earlier. :(
@feature
Carsten Haitzler
Marcel Hollerbach
Gustavo Sverzut Barbieri
Tom Hacohen