This reverts commit d93c4b2307.
Auto is not an option, and does not mean it'll be automatically
detected.
What auto means is that unless explicitly enabled/disabled it'll check
according to the build profile and will enable it automatically if using
the dev profile.
string identifying the build (vendor, maintainer, etc). It defines
EFL_BUILD_ID with default to "none". It can be used by applications
or for bug reports by including Efl_Config.h
Differential Revision: https://phab.enlightenment.org/D288
We need the wayland-scanner program to auto-generate the
subsurface protocol source files from subsurface.xml
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
this makes curl support a pure runtime-only thing. libcurl is loaded by
eina_module (dlopen/dlsym) when curl is actually first needed (when a
url connection/object is created). this means that ecore-con has no
link or compile dependencies on curl, only runtime, AND this saves
memory (due to curl inits using apparently a chunk of private pages).
so this saves memory and moves the dependency to runtime (though still
consider libcurl a dependency of efl - but like a binary executed,
it's at runtime).
So current order is :
- __builtin_bswap*() for compiler that provide it
- _byteswap_*() for MSVC
- bswap_*() for older Linux and some BSD
- own C code when everything else fall appart.
The reason for this order is that the builtin will always generate
the best assembly possible. On my system bswap_*() are not changing
in all version to the best solution as they are almost equivalent to
the C macro.
This add finally support for JPEG 2000, but be aware that libopenjpeg
is very badly managed. There is currently only version 1.5.x that does
provide the right files, is usable by a third party and portable. You
can seriously forget any other version.
Ecore_Evas_Drm will rely on Eeze for drm device discovery, so we need
to check for eeze requirements before ecore_evas.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
Allow ecore-wayland to be configured and compiled with xkbcommon 0.3.0.
Ecore-wayland does not use any of the new APIs in 0.3.1 nor is it exposed
to the bug that was fixed in 0.3.1.
Most distros don't include xkbcommon > 0.3.0 yet. Thus, if 0.3.1 is
required right now, then everyone is forced to build xkbcommon, too,
which contributes to dependency *madness*. Of course, anyone is still
welcome to build and link to xkbcommon 0.3.1 at will.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Reviewers: devilhorns, antognolli
Reviewed By: devilhorns
Differential Revision: https://phab.enlightenment.org/D203
Cedric BAIL
Cedric BAIL
Stefan Schmidt
Stefan Schmidt
Carsten Haitzler
Ryuan Choi
Tom Hacohen
Ryuan Choi
Chris Michael
Jerome Pinot
Jérémy Zurcher
Albin Tonnerre
Jean-Philippe Andre
Rafael Antognolli
U. Artie Eoff
discomfitor
Vincent Torri
Mike Blumenkrantz
Dan Mashal
David Walter Seikel
José Roberto de Souza