We need to build everythign else before. Without this dep running check-build
as first target from a fresh build will fail due to wrong dependency handling
(like no eolian run over the eo files, etc)
Inspired by D2489 from Kabeer Khan.
This problem have been observed by Scimmia22 on the Arch builds as well as on
the jenkins wayland build job. While compiling works fine the relinking during
make install fails with ecore-drm linking does not find eeze or eldbus as its
deps. This only shows on systems with no efl installed, a build from scratch.
As far as I can see we have all dependencies set correctly in configure as
well as in the Makefile which are working fine even in highly parallel builds.
It was a bit surprising here to me that the include order is still important
with our correct dependencies. Autotools wisdom is welcome here to either
explain to me why this is needed or what the correct fix would be.
The includes all moved before Ecore_Evas because that would use ecore_drm if
enabled.
Fixes T2281
Idea for this library is to become a retained mode drawing library that use
Eo/Eolian for its API and take a lot of the good design from Enesim by
Jorge Zapata and Jose Gonzalez (http://enesim.org/).
The intent of Emile is to be the common layer for serialisation, compression
and ciphering. It will expose the library we currently use internally to an
easier use from the outside (like gcrypt and lz4). It should improve portability.
Instead of pushing JSON, XML and what's not to Eina, I do think that they will
fit better in Emile.
As for the naming of Emile, you will need to be French and say :
"Un quoi ?" "Un serializer !"
Regarding why it is put there in the stack. Right now there is two users of
compression (eet and terminology), two users of cipher library (eet and ecore_con)
and a few handful of user for serialization (eina, eet, efreet, ecore_con, ...).
So the choice was quite simple, it needed to be below Eet. Now it could have been
on top of Eo or integrated into Eina.
One of the use case I am thinking of, is to compress Eo object when a canvas get
hidden/minized. For that it require Eo to use that library and it can't be a higher
level object. And with current implementation of Eo it is perfectly possible to
implement such idea. So not at Eo level.
As for Eina, I am starting to think it is getting to much things in its namespace.
I do believe that infact Eina_Simple_XML and Eina_File should after all have landed
in their own library. That's why I am putting the current logic in a new library.
It is going to expand, I want it to provide an few SAX like parser for JSON,
Eet_Data and protobuf with also an API like Eet_Data to directly feed those value
into a C structure without using a DOM at all. It would also be the right place
to experiment and benchmark for a new Eet_Data format that could be more efficient
to use.
So at the end, and due to how I see things going and being used, I do think it
is better of in its own library.
While install-exec-hook gets normally executed after install and
thus we would have this we need to ensure it here when we want to
be safe regarding parallel install.
Elocation is meant as a convenience library to ease application developers
the usage of geo information in their apps. Adding a geo tag to a picture or
translating an address to a GPS position and show it on a map widget are just
some of the use cases.
In the beginning elocation will rely on the GeoClue1 DBus service. Supporting
the new GeoClue2 DBus service is planned and worked on. GeoClue offers
providers for various techniques to get hold off the current position. Ranging
from GeoIP over wifi and GSM cell location to GPS.
This has been developed a while ago and was living in my private dev space.
It is about time to move this into EFL and bring it forward.
The detection of the GeoClue service is being handled on runtime and no new
dependency is added due to this library.
@feature
The C++ examples were being added twice. So the make distclean was tried after the Makefile was already removed.
Removes the EXAMPLES_SUBDIRS redundancy for the C++ examples.
Summary:
Applications can:
void method_callback(void* data, const Eldbus_Service_Interface* iface,
const Eldbus_Message* message);
struct { ... } data_struct;
Eldbus_Method methods[] =
{
"method1", ELDBUS_ARGS("b", "bool"), ELDBUS_ARGS("b", "bool"), ELDBUS_METHOD_FLAG_HAS_DATA
, (Eldbus_Method_Cb)&method_callback, &data_struct
};
And method_callback will be called with data parameter pointing to data_struct global object.
Also, Eldbus-cxx supports registering an interface passing a lambda or
function object as method. For example:
edb::service_interface iface = edb::service_interface_register
(c, path, interface
, es::method("SendStringAndBool"
, [expected_string, expected_bool] (std::string const& n, bool b
, bool* out)
{
std::cout << "Running SendStringAndBool" << std::endl;
ck_assert(n == expected_string);
ck_assert(b == expected_bool);
*out = b;
return n;
}
, es::ins<std::string, bool>("string", "bool")
, es::outs<std::string, bool>("string", "bool")
)
);
When a request for "SendStringAndBool" with the proper signature is
called, executes the lambda and replies with the return value and
its bool* out parameter value.
Reviewers: cedric, woohyun, raster
CC: savio, cedric
Differential Revision: https://phab.enlightenment.org/D1052
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:
Added HAVE_CXX11 guards to Makefile*.am files for C++ binding to avoid
compilation errors for examples when C++11 isn't supported. This also
disable installation of all EFL CXX pkgconfig files.
Reviewers: cedric, stefan, stefan_schmidt
CC: cedric, savio
Differential Revision: https://phab.enlightenment.org/D831
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>
The first object that we generate with Eolian is Evas_Line, as it is a
simple one.
Two files are generated during build:
- the .eo.c contains the APIs definitions invoking Eo, the Eo functions
extracting the parameters and calling the hand written functions and
Eo structures to define the objects. These hand written functions are
located in e.g evas_object_line.c.
- the .eo.h contains the APIs and Eo prototyes.
We will continue with the other objects. If you note something wrong,
please update us asap:
daniel.zaoui@samsung.comyossi.kantor@samsung.com
The point of this binding is to enable the support for easy lambda for ecore function
that wont be using Eo. See the tests on how to use those.
Reviewers: cedric, raster
CC: savio, cedric
Differential Revision: https://phab.enlightenment.org/D582
Signed-off-by: Cedric Bail <cedric.bail@free.fr>
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>
it was failing:
- leaving missing objects (.edj, .la)
- eo was not building its examples automatically with --enable-always-build-examples
- make dist with '--enable-always-build-examples' was not including 'src/examples'
plus lots of ignored files due test changes.
SVN revision: 82894
Instead of just making our own "check-local" and calling the binaries
ourselves, just append them into "TESTS" variable. Then they run after
all check_PROGRAMS are compiled.
The reasons for changing are:
1) If we change the test and call "make check" the test is not
compiled again -- and the only way to compile it is to "make clean".
2) There's no need to reinvent the wheel here.
With a recent version of Automake, the test output is redirected to log
files. This is good but unexpected for whom was used to the previous
way. So, be warned.
SVN revision: 82841
- they have no 'all' rule, keep out of SUBDIRS
- they depend on 'all-am', the non-recursive target that builds everything.
- they do not need a directory on its own to declare nothing.x
SVN revision: 82689
This one was a painful bitch. The edbus2 port was quite broken, mainly
leaking eina_stringshare and also not adding the '\0' to the strings
that are represented as bytearray (paths cannot be utf8 to avoid
translations).
Emotion plugin was also quite bogus and the video thumbnail as edje
(animated) is not working yet due bug in Edje_Edit api -- someone
needs to investigate this, seems strange.
Emotion plugin also had a bug that it was deleting the object from
inside object callback.
Now it seems to work. Please report if it does not.
SVN revision: 82675
this one was quite a huge work, but hopefully it's correct.
NOTES:
* removed vlc generic module, it should go into a separate package.
* gstreamer is enabled by default (see --disable-gstreamer)
* xine is disabled by default (see --enable-gstreamer)
* generic is always built statically if supported
* gstreamer and xine can't be configured as static (just lacks command line options, build system supports it)
* v4l2 is enabled by default on linux if eeze is built (see --disable-v4l2)
* emotion_test moved to src/tests/emotion and depends on EFL_ENABLE_TESTS (--with-tests), but is still installed if enabled.
TODO (need your help!):
* fix warnings with gstreamer and xine engine
* call engine shutdown functions if building as static
* remove direct usage of PACKAGE_*_DIR and use eina_prefix
* add eina_prefix checkme file as evas and others
* add support for $EFL_RUN_IN_TREE
* create separate package for emotion_generic_modules
* check docs hierarchy (doxygen is segv'in here)
SVN revision: 82501
Carefully compared 'svn export' and 'make dist' results and couple of
files were missing.
Changes:
* Makefile.am: removed all .pc from EXTRA_DIST, we shouldn't
distribute them here as they will contain ./configure data such as
install location.
* src/Makefile.am: moved all if-endif to files, otherwise EXTRA_DIST
won't work properly. We must EXTRA_DIST outside of the if-endif
block.
* static_libs/liblinebreak: removed couple of unused files.
SVN revision: 82241
this is still in progress, mostly the multisense stuff is pending.
it seems that when we merge ecore_audio in edje the libremix and
similar are gone, at least from Edje, and will be in ecore_audio
itself (or pulseaudio).
Changes:
* __UNUSED__ to EINA_UNUSED
* binaries (epp, embryo_cc, edje_cc) now consider EFL_RUN_IN_TREE and
will assume the binaries are still not installed, running from
build tree location (needs more testing, maybe doesn't work with
srcdir != builddir, still doesn't solve cross compile builds)
SVN revision: 82139
Changes also in this commit:
* fix missing EAPI in symbols used by modules
* removed old libudev and libmount support as agreed by discomfitor/zmike
* replaced __UNUSED__ with EINA_UNUSED
* fixed docs hierarchy
SVN revision: 82100
Disabled by default, enable with --enable-audio
ALSA support is disabled as it is not there yet. Pulseaudio should work
though.
Support for .ogg and .wav is there as well (.mp3 is not)
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
SVN revision: 81000
After agreement in the mail list, core developers agree to remove this
engine that was not being supported for a long time.
Given that most operations Evas uses are not accelerated in DirectFB,
or at least hardware that exclusively supports DirectFB, it's better
for those people to just use Evas/Ecore software (buffer) rendering
and expose DirectFB's framebuffer as destination surface.
SVN revision: 80232
I've tested make -j 3 install and it works nicely
I've tested expedite with software and opengl xlib,
and it works. Not tested other engines, so please
report any problems (engines or other) on the ML.
TODO: examples and tests, I'll add them later
ISSUE: Eina_Unicode size check. It indirectly depends on
eina_config.h, which is created at the end of the
configure script. So its size is always 0. I don't
know how that size is used, so I can't do a lot,
for now.
SVN revision: 78895
Please check.
note1: Only lib and bin for now, but should be extended to other stuff
note2: distcheck does not work because eo_suite is failing.
SVN revision: 78758
Introduced --with-profile={dev,release} that will simplify how to set
build options of EFL.
NOTE-1: specific e17 benchmark is now gone, it will always be built
and is the default benchmark for eina. If we want to have a faster
benchmark in the future, just add a command line option for
eina_suite.
NOTE-2: valgrind build is broken as it needs -fPIC. Will get to it
later. Likely someone needs to revisit the eina mempools for valgrind
and other basic tools (eo? likely evas).
SVN revision: 77771