I found that results of build are different by build tools.
this patch fixes meson.build to make results same as a way it does in autotools.
Differential Revision: https://phab.enlightenment.org/D7819
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
Like 79d76fb25e, this is useful when
debugging a core dump.
It accepts a valid pointer to an object, for example as returned from
$eo_resolve, and a name of a class or mixin, and returns a pointer to
the private data. Essentially the same as efl_data_scope_get(), but also
works on core dumps, and accepts a class name instead of a class
pointer.
Usage:
Print the pointer:
(gdb) print $eo_data_get($eo_resolve(obj), "Efl_Canvas_Object")
$1 = (void *) 0x555555eb9290
Use it directly (e.g. to print a value):
(gdb) print ((Evas_Object_Protected_Data *) $eo_data_get($eo_resolve(obj),
"Efl_Canvas_Object"))->last_event_type
$2 = EVAS_CALLBACK_MOUSE_UP
@feature
Normally when debugging Eo with gdb you can just use any of the internal
eo functions to resolve the id to its internal pointer. However, when
loading a coredump you can't execute any code, not even the id resolve
code.
This change adds a gdb function that resolves the id to its pointer form
without executing any code in the process space. This plugin is
essentially the id resolve code written in python as a gdb function.
Usage:
Print the pointer:
(gdb) print $eo_resolve(obj)
$1 = (_Eo_Object *) 0x5555559bbe70
Use it directly (e.g. to print the class name):
(gdb) $eo_resolve(obj)->klass->desc.name
This plugin requires that the coredump would be loaded with the exact
same libeo.so binary (or at least one that hasn't changed eo internals),
and that the debug symbols for libeo.so would be available for gdb to
use.
Note:
This feature is incomplete and only resolves IDs that are owned by the
main thread and in the main domain. This is not a big issue at the
moment, because almost all of our IDs are like that.
@feature
This major mode provides colored output, that helps a lot to view and
edit ".eo" and ".eot" files.
It's the first version, I still see some indenting issues with
toplevel blocks such as struct and enums. Nonetheless it's much more
useful than fundamental-mode (pure text).
This reverts commit 4850c53350.
You can set the alias in the .gdbinit.
So my .gdbinit looks like:
source /usr/local/share/eo/gdb/eo_gdb.py
alias -a eo_bt = eo_backtrace
Special thanks to Alex-P. Natsios for the tip.
If you install the efl to a different path than the one gdb was installed to
either set gdb's data dir, or just symlink the file to the other prefix.
You can still use the old method of just loading the module.
stepping over Eo.
To do it:
- Write in ~/.gdbinit "source prefix/share/eo/eo_step.py" (prefix is usually/opt/e17)
- in gdb, when arriving to eo_function (eo_do, eo_do_super), execute
eo_step. This script will step into the code until it reaches a function
that doesn't belong to libeo.
Because of a bug in gdb that will be fixed in 7.6, if after having used the
script once, you rerun your application and reexecute the script, a
segmentation fault can occur. Sorry for the inconvenience.
Signed-off-by: Daniel Zaoui <daniel.zaoui@samsung.com>
SVN revision: 80760
Wonki Kim
Marcel Hollerbach
Tom Hacohen
Gustavo Sverzut Barbieri
Mike Blumenkrantz
Cedric Bail
Daniel Juyung Seo
Daniel Zaoui