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>