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).
Enable 3D features using --enable-evas-3d=yes when configuring.
APIs are exposed through Evas_3D.h.
Currently, evas-3d is being supported only on gl_x11 engine.
Conflicts:
src/lib/evas/Evas_Eo.h
Due to the amount of generated debug messages from eolion generation
we end up with 3.8GB log files for elm builds when efl was build with
coverage enabled. Temporary disable this until eolion is fixed and
we can turn it on again.
Added eet into internal dependencies for ecore_evas_connect, ethumb, ethumb_client
I got below errors for ecore_evas_connect, ethumb, ethumb_client
lib/evas/.libs/libevas.so: undefined reference to `eet_data_image_colorspace_get'
lib/evas/.libs/libevas.so: undefined reference to `eet_data_image_read_to_cspace_surface_cipher'
collect2: error: ld returned 1 exit status
The autogenerated check macro by autotools lead to a huge number of file
being added on the command line of a script, when the only things it does
is to test for the definition of those strings.
Hoping this is going to fix the problem. If that doesn't we will need to write
our own CHECK macro here.
The TGV file format is specifically created for Evas. It is designed to allow
region decompression and parallele decompression with a fast path for GPU that
do handle ETC1 compression. Plan for adding other compression method will come
later.
To build SDL with OpenGL ES we need a SDL version which ships these headers
which only starts with SDL 2.x. So we only allow it for full OpenGL right
now until someone wants to port our code over to SDL 2.x
Fixes T856
@fix
configure: fix prerequisite header issue
Summary:
in some platforms like openBSD <sys/socket.h> must be included before
net/if.h
the canonical way to ensure that with autotools is by providing that
fourth directive.
evas: use MAP_ANON instead of MAP_ANONYMOUS
Stupid unpredictable standards (or not so standard).
MAP_ANON exists and is defined almost anywhere unlike MAP_ANONYMOUS
Let's use that for portability's sake (they are practically identical
anyway)
Reviewers: raster, cedric
Reviewed By: cedric
CC: cedric
Differential Revision: https://phab.enlightenment.org/D616
Signed-off-by: Cedric BAIL <cedric.bail@free.fr>
@feature: Add xkbcommon as a dependency for ecore_drm so we can
process input keys
In order for keyboard input to work for ecore_evas_drm, we will need
to translate keypress events into meaningful key names, so require
xkbcommon to deal with the translation.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Some people (I'm one of them) will do user-local builds of EFL and
don't want to install services in /usr, or provide links, rather
choosing to install in ~/.local/share/dbus-1. Then figure out this
case and do not show an alert when the setup is ready.
As we mention $XDG_DATA_DIRS in our alert, we should not do the alert
when the user follows its recommendation. This is now checked.
And handle systemd services if they are used.
If the dbus service contains SystemdService entry and the dbus-daemon
is started with --systemd-activation, then requests for services on
the user session bus will be handled by systemd, creating cgroups and
being handled as native systemd services of Type=dbus.
Added edje into internal dependencies for ethumb_client.
I got below error.
/usr/elocal/lib/libedje.so.1: undefined reference to `evas_object_line_class_get'
collect2: error: ld returned 1 exit status
make[4]: *** [bin/ethumb_client/ethumbd] Error 1
make[4]: *** Waiting for unfinished jobs....
@bugfix: Drm is optional, so ecore-evas should not internally depend
on it unless ecore-drm is found.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
Instead of relying on ${prefix}/share to be the default for ${datadir} or
${dbusservicedir} use the actual paths where the files will be placed.
Somewhat tricky because of autoconfs desire to keep prefix changeable but
continuously evaluating the variables until they don't change work.
Reviewers: raster, englebass
Reviewed By: raster
CC: cedric, stefan_schmidt
Differential Revision: https://phab.enlightenment.org/D581
The goal of this library is to make the life of C++ developers easier
when having to manipulate Eina datatype by providing a layer to abstract
those data type in C++. Check examples for now. Documentation will come
soon, but we are pushing that rather sooner to get feedback on those bindings.
As you will notice, this library is just composed of headers. There is no .so
and we do think it is better this way. Reducing ABI and API stability issue for
applications developers who are the primary target of this binding.
Also please note that you will need to have C++11 to use this binding.
Signed-off-by: Cedric Bail <cedric.bail@free.fr>
now that we don't load modules from user dirs anymore - just system,
we can nuke os/arch from module dir and just keep version. since abi
for a module should be stable for a 1.X release series, we dont need
micro, just 1.9 (or 1.10 etc.). this makes thnigs a bit cleaner and
simpler for emotion_generic_players
It is to fix possible build break of ethumb
I got below message.
lib/edje/.libs/libedje.so: undefined reference to `ecore_imf_context_retrieve_selection_callback_set'
collect2: error: ld returned 1 exit status
make[4]: *** [bin/ethumb/ethumb] Error 1
apparently I read the commit order wrong and this fix went in for 1.4.0, not 1.3.2, which means anyone who has 1.3.2 has been having lots of fun crashes for the past 24 hours
this was a fixme which was likely written sometime before July 2010 when the bug was fixed, just prior to the 1.3.1 release. I think it's probably okay to require that release since it's been 3+ years.
ac_cv_prog_cc_c99 being empty just means there is no need to add
any flags for the compiler to be C99-capable.
"no" means the compiler isn't C99-capable.
The check is actually unnecessary as EFL demands a C99-capable
compiler these days but if that every changes ...
Reviewers: zmike
CC: cedric
Differential Revision: https://phab.enlightenment.org/D443
Signed-off-by: Cedric BAIL <cedric.bail@samsung.com>