a reason for doing that is that you can just pack together targets into
a array and pass them to our helper, and the helper will just handle
them, so even module with eldbus codegen etc is now supported.
This also means that we are just passing the src object directly into
the shared_module call, which means the user of our helper can just pack
everything he needs into the src var and the helper does not need to
know about it.
now mdoule build files that fllow one pattern (the most common by far)
all JUSt list their souce files and nothing else. this really cuts
down on build size/complexity.
there are other patterns too (no icons at all) that i'll do next, then
we're down into "weird" land where i'll have to think of some more
interesting ways to deal with this.
so we';re missing installing desktop files. edj icon files, wizard
data files in the wrong place, and much more. this also cleans up the
module meson build of pretty much all modules and make their build
files cimple and consistent so it's far easier to re-use things from
one module to the next. we should aim for simplicity, consistency
between as much as possible so we can refactor and turn into maybe
functions later. imho that starts with consistency though. until i can
see all the common patterns clearly, i don't want to write functions
yet. it's easier to see if all the files are consistently using the
same vars and formatting etc. etc. etc.
but either way the installation needs fixing so it installs all files
in the right places with the right permissions etc. etc. etc.
this doesn't fix all module build files bt all the ones i found that
were broken installs and they use what i think is a cleaner/simpler
template, BUT there is far too much copy & pastage here... far too
much.i need to find a cleaner way to automate this.
==20443== Invalid read of size 8
==20443== at 0x28CED526: _bar_exec_new_show (bar.c:980)
==20443== by 0x819D78D: _eo_evas_object_cb (evas_callbacks.c:184)
==20443== by 0xDFB6FED: _event_callback_call (eo_base_class.c:1496)
==20443== by 0xDFB7373: _efl_object_event_callback_legacy_call (eo_base_class.c:1569)
==20443== by 0xDFB743A: efl_event_callback_legacy_call (eo_base_class.c:1572)
==20443== by 0x81DC562: _efl_canvas_object_efl_object_event_callback_legacy_call (evas_object_main.c:993)
==20443== by 0xDFB743A: efl_event_callback_legacy_call (eo_base_class.c:1572)
==20443== by 0x819E1F8: evas_object_event_callback_call (evas_callbacks.c:404)
==20443== by 0x81E6B23: evas_object_inform_call_show (evas_object_inform.c:13)
==20443== by 0x81DECA2: _show (evas_object_main.c:1689)
==20443== by 0x81DF0E7: _efl_canvas_object_efl_gfx_visible_set (evas_object_main.c:1810)
==20443== by 0xDD670B9: efl_gfx_visible_set (efl_gfx.eo.c:21)
==20443== by 0x81DEA93: evas_object_show (evas_object_main.c:1639)
==20443== by 0x483706: _e_comp_intercept_show_helper (e_comp_object.c:1754)
==20443== by 0x483761: _e_comp_intercept_show (e_comp_object.c:1768)
==20443== by 0x81E7536: evas_object_intercept_call_show (evas_object_intercept.c:71)
==20443== by 0x81E7ED2: _evas_object_intercept_call_internal (evas_object_intercept.c:103)
==20443== by 0x81E88B0: _evas_object_intercept_call_evas (evas_object_intercept.c:236)
==20443== by 0x81DF0CA: _efl_canvas_object_efl_gfx_visible_set (evas_object_main.c:1807)
==20443== by 0xDD670B9: efl_gfx_visible_set (efl_gfx.eo.c:21)
==20443== by 0x81DEA93: evas_object_show (evas_object_main.c:1639)
==20443== by 0x4A6793: _e_desk_show_begin (e_desk.c:821)
==20443== by 0x4A4E39: e_desk_show (e_desk.c:312)
==20443== by 0x537C2E: _e_int_menus_clients_item_cb (e_int_menus.c:1624)
==20443== by 0x548D3F: _e_menu_active_call (e_menu.c:2056)
==20443== by 0x54ABFB: _e_menu_cb_mouse_up (e_menu.c:2789)
==20443== by 0xC636B66: _ecore_call_handler_cb (ecore_private.h:325)
==20443== by 0xC637B3F: _ecore_event_call (ecore_events.c:518)
==20443== by 0xC641158: _ecore_main_loop_iterate_internal (ecore_main.c:2397)
==20443== by 0xC63EC7E: ecore_main_loop_begin (ecore_main.c:1299)
==20443== by 0x43DE81: main (e_main.c:1081)
==20443== Address 0x20 is not stack'd, malloc'd or (recently) free'd
==21266== 3,488 (96 direct, 3,392 indirect) bytes in 2 blocks are definitely lost in loss record 10,417 of 10,680
==21266== at 0xE1E5D49: _eina_chained_mempool_alloc_in (eina_chained_mempool.c:212)
==21266== by 0xE1E5FDC: eina_chained_mempool_malloc (eina_chained_mempool.c:324)
==21266== by 0xE1A016E: eina_mempool_malloc (eina_inline_mempool.x:90)
==21266== by 0xE1A03C2: _eina_list_mempool_list_new (eina_list.c:222)
==21266== by 0xE1A11C5: eina_list_append (eina_list.c:578)
==21266== by 0x2910B667: _bar_fill (bar.c:1565)
==21266== by 0x2910D1A5: _bar_recalculate_job (bar.c:2047)
==21266== by 0xC602C2C: _ecore_job_event_handler (ecore_job.c:98)
==21266== by 0xC5FBBCE: _ecore_call_handler_cb (ecore_private.h:317)
==21266== by 0xC5FCB5D: _ecore_event_call (ecore_events.c:518)
==21266== by 0xC605EEB: _ecore_main_loop_iterate_internal (ecore_main.c:2381)
==21266== by 0xC603C99: ecore_main_loop_begin (ecore_main.c:1289)
==21266== by 0x43DD0D: main (e_main.c:1089)
==25839== 8,576 (6,432 direct, 2,144 indirect) bytes in 134 blocks are definitely lost in loss reco$
==25839== at 0xE812A41: _eina_chained_mempool_alloc_in (eina_chained_mempool.c:212)
==25839== by 0xE812CD4: eina_chained_mempool_malloc (eina_chained_mempool.c:324)
==25839== by 0xE7CCFED: eina_mempool_malloc (eina_inline_mempool.x:90)
==25839== by 0xE7CD241: _eina_list_mempool_list_new (eina_list.c:213)
==25839== by 0xE7CE044: eina_list_append (eina_list.c:569)
==25839== by 0x29E2CF07: _bar_check_for_duplicates (bar.c:58)
==25839== by 0x29E30D7F: _bar_cb_exec_client_prop (bar.c:1281)
==25839== by 0xDBD7AF6: _ecore_call_handler_cb (ecore_private.h:317)
==25839== by 0xDBD8A85: _ecore_event_call (ecore_events.c:518)
==25839== by 0xDBE1AEF: _ecore_main_loop_iterate_internal (ecore_main.c:2380)
==25839== by 0xDBDF89D: ecore_main_loop_begin (ecore_main.c:1290)
==25839== by 0x441C04: main (e_main.c:1093)
So yeah, I've literally used sed to replace every occurrence of
ecore_time_add() with ecore_timer_loop_add() because I'm reasonably
confident that no part of E has a legitimate need for timer based on the
exact current time.
It would be really nice if I'm not wrong. :)
The reason for this is the incredible spew of clock_gettime() calls I'm
seeing on an ARM system (that should have a vdso for gettime, but...)
This can amount to thousands of system calls per second.
#YOLO
==15191== Invalid read of size 8
==15191== at 0x2B6328A7: eina_list_next (eina_inline_list.x:32)
==15191== by 0x2B637520: _bar_empty (bar.c:1405)
==15191== by 0x2B639301: _bar_recalculate_job (bar.c:1958)
==15191== by 0xDBDA800: _ecore_job_event_handler (ecore_job.c:98)
==15191== by 0xDBD3AC6: _ecore_call_handler_cb (ecore_private.h:317)
==15191== by 0xDBD4A55: _ecore_event_call (ecore_events.c:518)
==15191== by 0xDBDDABF: _ecore_main_loop_iterate_internal (ecore_main.c:2380)
==15191== by 0xDBDB86D: ecore_main_loop_begin (ecore_main.c:1290)
==15191== by 0x441A94: main (e_main.c:1093)
==15191== Address 0x1ff97dc8 is 6,520 bytes inside a recently re-allocated block of size 8,192 alloc'd
Marcel Hollerbach
Carsten Haitzler
Mike Blumenkrantz
Stephen 'Okra' Houston
Andy Williams
Derek Foreman
Stephen Houston