Summary: Ecore_Drm is going to be using Eeze for udev functionality,
so we need to check for Eeze deps before Ecore_Drm
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Sumary: Ecore_Drm will use Eldbus library for dbus functionality, so
we need to check for Eldbus first before Ecore_Drm
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Added eet into internal dependencies for ethumb_client
I got below errors for ethumb_client
CCLD bin/ethumb_client/ethumbd
lib/edje/.libs/libedje.so: undefined reference to `ecore_imf_context_input_hint_set'
lib/edje/.libs/libedje.so: undefined reference to `ecore_imf_context_input_hint_get'
collect2: error: ld returned 1 exit status
@fix
Summary:
This fixes following build script problems for ecore_evas_drm engine module.
1. Missing link to gbm for ecore_evas_drm if '--enable-gl-drm' option is given.
ecore_evas_drm engine is using gbm function if it builds with that config option.
To be more exact, ecore_evas_gl_drm_new_internal function needs gbm.
Thus we need to add gbm library linking '-lgbm' to ecore_evas_drm engine module
if '--enable-gl-drm' option is given. I've added this build script to
m4/ecore_check_module.m4 file.
2. Wrong gbm dependency check code in configure.ac
EFL_OPTIONAL_INTERNAL_DEPEND_PKG m4 macro function is designed for checking
dependency of efl internal libraries. Thus we should remove gbm pkg name when
configuring ecore_evas_drm engine module. It would be better to move dependency
check for gbm to m4/ecore_check_module.m4 file. And one more thing want_drm
value has to be changed to want_gl_drm in ECORE_EVAS_MODULE([gl-drm]...).
3. BUILD_ECORE_EVAS_OPENGL_DRM macro is always defined in configure.ac.
This kind of macro, BUILD_EFL_MODULE_NAME, has to be defined only if given module
is enabled. But this macro value was just defined with no test.
And it is even useless, we can use BUILD_ECORE_EVAS_GL_DRM macro which is defined
by ECORE_EVAS_MODULE([gl-drm], [${want_gl_drm}],...) function.
So I've removed that from configure.ac.
Test Plan:
1. Configure with --enable-gl-drm:
$ ./autogen.sh --enable-drm --enable-gl-drm
2. Build:
$ make && make install
3. Check module.so of ecore_evas_drm engine whether it has a library dependency with gbm:
$ readelf -a $EFL_GIT/src/modules/ecore_evas/engines/drm/.libs/module.so | grep NEEDED
Reviewers: raster, stefan_schmidt, devilhorns
Reviewed By: devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1379
Summary: The '-e' option does not exist in BSD-echo, nevertheless it behaves by default like the "echo -e" of the GNU-echo.
Reviewers: raster, cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1376
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
IVI-Shell is a wayland shell implementation for in-vehicle infotainment.
Summary: This is a set of patches proposed to implement IVI-Shell (https://phab.enlightenment.org/T1552).
Reviewers: ntanibata, devilhorns
Subscribers: mbachmann
Projects: #efl
Differential Revision: https://phab.enlightenment.org/D1350
@feature
While we are likely will keep the embedded copy for a while to avoid a really
new dependency we allow now to use the external liblz4. You need at least
revision r120 and a package that ships the pc file for it.
Personally I would like to get rid of it rather sooner than later due to the
security implications and a bunch of code we ship but have no idea about.
Reality is that it will need some time until this new lib is actually
packaged and shipped with releases for a a majority of people.
This patch was co-worked with Doug Newgard <scimmia22@outlook.com>
Summary: Support of Spinlocks in Eina (Eina_Spinlock) for OSX, which does not implement them in pthread.
@feature
Reviewers: raster, raoulh, naguirre, cedric, stefan_schmidt
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1151
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary: This is the first step to introduce a gl-drm backend.
Test Plan: "ecore evas" create with ecore_evas_gl_drm_new(). It creates "ecore evas" with gl_drm evas backend.
@feature
Reviewers: raster, Hermet, cedric, devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1187
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This reverts commit bf8aba5f9f.
This warning is actually wanted. We do want to know when things get deprecated and
not discover that to late. This warning come from the use of gettext 0.17. Once we
move out of it, we will be fine. As a reminder and for keeping track of other
future deprecated macro, we should never use that flag !
Note: This is the second time I revert such a patch, I would really like people
stop disabling warning with this nasty work around.
Summary:
Below was the warning:
configure.ac:247: warning: The 'AM_PROG_MKDIR_P' macro is deprecated, and its use is discouraged.
configure.ac:247: You should use the Autoconf-provided 'AC_PROG_MKDIR_P' macro instead,
configure.ac:247: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your Makefile.am files.
@fix
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1341
Reverts 21da4a5454.
It is needed to generate Makevars in-tree even when building out-of-tree because of
how Autotools work. However, distcheck doesn't properly remove the Makevars file in
the generated distdir and makes po/ read only, preventing the build system from
generating an up-to-date version of Makevars. This commit adds the required hooks
needed to fix this behavior.
With commit 6030b9de79 the internal name EFL
name was changed to EFLALL but the needed CFLAGS and LDFLAGS for coverage
have not been adjusted. Thus it was simply no longer producing the gcda
files needed by lcov.
All back now and it shows an amazing jump in our coverage to:
Overall coverage rate:
lines......: 31.6% (45827 of 144975 lines)
functions..: 41.1% (5620 of 13684 functions)
Summary:
With removing of pkgconfig checking on EVAS_CHECK_ENGINE for drm,
evas_drm engine need to setup libs including internal ecore-drm.
But, the evas_drm engine have missed ecore-drm libs because it have been
done after finishing setup library of evas.
This revision moves setup dependendency for ecore-drm into proper place.
Test Plan:
1. Build EFL with --enable-drm
2. ELM_ENGINE=drm E_WL_FORCE=wayland_shm enlightement_start
Reviewers: gwanglim, devilhorns, stefan_schmidt
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1249
This reverts commit dd37d2bc07.
This breaks make distcheck. Looking at this commit I really wonder if it does
anything good. It seems to work for po_makefile_in. It also breaks for
distcheck which is using out of tree builds in the _build folder.
If someone can explain me why something like this is needed for makevars I
want to hear it. getting a fix in that does not break distcheck would be fine
I guess.
At the moment we use the fake "efl" library as a dependency for
everything and use it as a way to have global cflags and lib deps. This
is bad as we'd like to have a "real" libefl.
I changed EFL to EFLALL as the new name. Easy to change to something
else if anyone finds this name lacking. It's internal.
Using pkgconfig for internal libs turns out to be not a really good idea. It
works fine if you already have an efl install with the needed ecore-drm.pc
file but it will fail if you build from scratch.
We already have a m4 macro for these internal dependencies. Make use of it
for the evas drm engine depending on ecore-drm.
Fixes T1432
At least with systemd 208 there is no pc file for just libsystemd. It is split
into daemon id128 journal and login. We only need login here so only require it.
Eldbus works asynchronously, but we need syncronous method calls to
get the replies from opening input devices, so let's just use normal
dbus
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Ecore_Drm will now require dbus, systemd, and systemd-login support in
order to open input devices as a normal user
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This reverts commit ff5a57aafd.
Edje is not using dlopen directly but luajit is. Seems some distros are missing
dlopen for there luajit package. Nothing we should workaround here.
Summary:
AC_HELP_STRING --> AS_HELP_STRING
AC_TRY_COMPILE --> AC_COMPILE_IFELSE + AC_LAGN_PROGRAM
those are deprecated for almost 10 years
autoupdate tool do this automatcally.
@fix
Reviewers: raster, cedric, stefan_schmidt
CC: cedric
Differential Revision: https://phab.enlightenment.org/D1088
will be used to handle i18n for lua files in EFL (because only gettext 0.18.3+ supports Lua) and it'll be usable standalone too, it will also be able of handling more things than lua support in xgettext does (e.g. concatenated string literals will be considered one string)
Elua is a LuaJIT based runtime for the EFL meant to provide facilities for rapid application development. The name is temporary. The EFL bindings will be generated with Eolian. @feature
This allows people to disable the building of anything GUI related.
In my case, it is used for servers.
I encourage anyone that think they can do a better patch to improve it,
as i dislike having to add all those AM_CONDITIONAL().
Maybe the macros should be improved.
Summary:
Vanish with these:
src/Makefile_Eolian_Helper.am:15: warning: '%'-style pattern rules are a GNU make extension
src/Makefile.am:36: 'src/Makefile_Eolian.am' included from here
src/Makefile_Eolian.am:42: 'src/Makefile_Eolian_Helper.am' included from here
src/Makefile_Eolian_Helper.am:18: warning: '%'-style pattern rules are a GNU make extension
src/Makefile.am:36: 'src/Makefile_Eolian.am' included from here
src/Makefile_Eolian.am:42: 'src/Makefile_Eolian_Helper.am' included from here
src/Makefile_Eolian_Helper.am:21: warning: '%'-style pattern rules are a GNU make extension
Reviewers: tasn, cedric
CC: JackDanielZ, smohanty, felipealmeida, raster, cedric
Differential Revision: https://phab.enlightenment.org/D894
Signed-off-by: Cedric Bail <cedric.bail@free.fr>
Summary:
EFL_PTHREAD_CFLAGS are needed for tests and users that use
efl::eina::thread's and EFL_PTHREAD_LIBS to eina_cxx, eo and evas examples.
Reviewers: cedric, stefan, stefan_schmidt
CC: cedric, savio
Differential Revision: https://phab.enlightenment.org/D832
Signed-off-by: Cedric Bail <cedric.bail@free.fr>
Summary:
This patch fixes T1226 by adding a Makefile.examples to
examples/eolian_cxx. It also fixes a bug in bin/eolian_cxx: the
include paths were not being correctly generated for directories
outside EFL tree.
Reviewers: cedric, smohanty, stefan_schmidt, stefan
CC: uartie, wayland-efl, felipealmeida, raster, woohyun, cedric
Maniphest Tasks: T1226
Differential Revision: https://phab.enlightenment.org/D824
Signed-off-by: Cedric Bail <cedric.bail@free.fr>
Summary:
Fixed distcheck for Eolian C++. Made the generated files as
nodist so it doesn't get picked up for generation way too
early.
Reviewers: cedric, seoz
CC: cedric
Maniphest Tasks: T1220
Differential Revision: https://phab.enlightenment.org/D820
Signed-off-by: Cedric Bail <cedric.bail@free.fr>
Summary:
This patch adds 'eolian_cxx' -- a C++ bindings generator --
to the EFL tree. Eolian Cxx uses Eolian API to read .eo files and generate
.eo.hh. It relies/depends on Eo Cxx and Eina Cxx (both non-generated
bindings).
src/bin/eolian_cxx: The eolian_cxx program.
src/lib/eolian_cxx: A header-only library that implements the C++ code
generation that binds the .eo classes.
=Examples=
src/examples/eolian_cxx/eolian_cxx_simple_01.cc: The simplest example,
it just uses some "dummy" generated C++ classes.
src/examples/eolian_cxx/eolian_cxx_inherit_01.cc: Illustrates how
pure C++ classes inherit from .eo generated classes.
src/examples/evas/evas_cxx_rectangle.cc: More realistic example using
the generated bindings Evas Cxx. Still a bit shallow because we don't
have full fledged .eo descriptions yet, but will be improved.
=Important=
The generated code is not supported and not a stable API/ABI. It is
here to gather people interest and get review before we set things in
stone for release 1.11.
@feature
Reviewers: cedric, smohanty, raster, stefan_schmidt
CC: felipealmeida, JackDanielZ, cedric, stefan
Differential Revision: https://phab.enlightenment.org/D805
Signed-off-by: Cedric Bail <cedric.bail@free.fr>
We only support the Wayland EGL engine build with OpenGL ES but not full
OpenGL. Reflect this in our configure to avoid compile errors after a
successful configure run. Fixes T1202
@fix
Since Lua is already a dependency for Edje, I believe it is safe
to add it as a dependency for Evas as well.
This will be used to replace the (bad) scripting language used for
the Evas filters (text effects).