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
this allows only /dev/fb[0-0] or /dev/fb/something where somthing does
not begin with a . - thus no way to break out of the fb subdir... so
it should be ok... this keeps setuid safety and allows this env var to
work now as intended in this situation.
If buf->priv.fb.fb was NULL the function would have crashed. So
buf->priv.fb.fb can't be NULL. I'm keeping the if(buf->priv.fb.fb)
anyway, but not sure the else case is valid.
Thanks @jiin.moon for the report.
Summary:
I thought its better to fail and return null if realloc fails than to
continue. So returning by closing all openend file.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: cedric, illogict
Differential Revision: https://phab.enlightenment.org/D3232
Summary: Gcc suggested parens around the truth value here, however
as some developers don't like overly used parens, just modify the code
slightly to not use an if on the assignment line.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
Add NULL type check in output_free of evas fb engine.
If engine setup is failed,
Render_Engine wil be NULL so output_free also need to
handling NULL check.
Test Plan:
It needs specific condition to reproduce,
engine of ecore_evas is set to fb, and setup is failed,
then Render_Engine is NULL, but ecore_evas_free will call
output_free in fb engine's evas_engine.c
Reviewers: raster, cedric, Hermet
Reviewed By: Hermet
Subscribers: cedric, seoz, eagleeye, singh.amitesh
Differential Revision: https://phab.enlightenment.org/D2743
@bugfix: structure fb_var_screeninfo does not have a colorspace field
defined in linux/fb.h, so (for now) comment out code which was
referencing that field. Not sure what the intent was here, but build
was broken because of this.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
While most framebuffes use stride = width, some may have stride bigger
than width to provide better alignment. Then we must always use stride.
Thanks to Arjan van de Ven, the one that spotted the issue.
@fix
FrameBuffer can be tricky with all combinations and it's hard to tell
users to send useful information, then print the information we use so
we can get useful bug reports.
clean evas_fb_main.c so it returns -1 to indicate invalid fds, same as
open() and what is written in evas_fb.h example.
call fb_cleanup() in all error conditions and always return -1 in
fb_postinit() if we did call fb_cleanup().
this makes efl ignore certain env vars for thnigs and entirely removes
user modules (that no one ever used) etc. etc. to ensure that *IF* an
app is setuid, there isn't a priv escalation path that is easy.
Being annoyed by different types of eina critical macros - CRI, CRIT,
CRITICAL -, I concluded to unify them to one. Discussed on IRC and
finally, CRI was chosen to meet the consistency with other macros -
ERR, WRN, INF, DBG - in terms of the number of characters.
If there is any missing bits, please let me know.
Evas_Common.h should be used for the public header, and rather rename
evas_common.h internal header to another name.
Sa:
Evas_Common_Header.h -> Evas_Common.h
evas_common.h -> evas_common_private.h
Shouldn't have both Evas_Common.h and evas_common.h because of case
insensitive filesystems.