This backend has received no patch and maintenance from anyone who could
actually test it over the last few years. After talking with KaKaRoTo it
is best to remove it. If anyone want to take over its maintenance, you
are welcome to revert this patch.
the previous method of forcing this to be enabled for dist builds caused
breaks when the original configure disabled examples, as the little-known
DISTCHECK_CONFIGURE_FLAGS variable would need to also be set to disable
examples even though the user would think they were disabled based on configure
output
this would previously break if:
* cxx bindings were disabled
* elua was disabled
* base configure disabled examples and dist build disabled examples
* base configure disabled examples and dist build enabled examples
it still breaks if:
* base configure disables examples and dist build enables examples
Our systemd service files are installed into an absolute system path by default
which simply does not work when doing a distcheck. Set the path differently for
the distcheck options.
In case a warning gets printed from lcov some internal function changes the dir
to / and thus fails to create files in the given file later on. Using an
absolute path here is a workaround to avoid this problem. The fix is in lcoc
already but not yet in any release so we better keep this around here.
Lcov fix reference:
632c25a0d1
I have seen hangs with gcov on Jenkins and locally where the processing just
keeps spinning in an infinite loop. From what I have found out this boils down
to using gcov --all-blocks which is what lcov does with branch coverage enabled.
It is supposed to be fixed in gcc 4.8+ but I see this here with 5.3.1. So its
either a regression or not completely fixed. In any case we will ignore branch
coverage for now. I hoped it would work well but it did only for a while and
having line and function coverage is better than having nothing.
These files are not getting cleaned up as they are not integrated into the rest
of our build system. These are the extra makefiles to build build only eina, eo,
etc.
The trick with -C clean does not work here for me and this is the only way I
found to get a distcheck going through. Which is kinda important given we want to
do the first alpha tarballs for 1.18 next Monday.
Libuwind may not be shipped with a pkg-config file.
It can be distributed on the system, but the autotools
would fail to detect it because it relied only on pkg-config.
We now first check with pkg-config, and then try to compile and
link a program using libuwind to see if it is supported anyway.
This is a first step towards a working eina_log_backtrace on
Mac OS X.
This new library is going to replace the existing Ecore_Drm. This will
refactor a lot of the code, bring improvements over the existing API,
and provide additional support for missing features.
@feature
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
The elput library is an efl abstraction for the libinput library which
can be used by various other subsystems (ecore_fb, ecore_drm, etc) to
handle interfacing with libinput without having to duplicate the code
in each subsystem.
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
EGL Fullscreen is a module intended to support many proprietary GL driver that come
with custom API to create framebuffer/window. This one is starting by covering Android
with libhybris/hwcomposer. Later on, it should be able to support easily the Raspberry Pi
driver.
At this moment this does not work properly. Activate it at your own risk ! Do not report
bug if you don't know what you are doing :-) A backend for Ecore_Evas will come later on
along with a patch for Ecore_FB to use libinput. Finally a few patch should hopefully
enable this backend to work and compile more easily (relying on proper header detection
and dlopen/dlsym for access to proprietary function).
You can read more about the goal of this patch by reading our wiki at :
https://phab.enlightenment.org/w/boot2efl/
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
The lcov tool offers the functionality to have an initial run over the code base
before the tests are executed to make sure it catches all files, even the ones
that are not loaded during the test run.
This is something we missed so far. The reports have only been in relation to
the files that actually have been loaded during the test. We missed quite a
few files which made our numbers inaccurate. Things like
modules/emotion/gstreamer1 have no tests yet and thus never showed up in the
coverage report. While it has 103 functions and over thousand lines which need
to get covered. With the baseline this is handled now. Thanks goes to the folks
at LibreOffice who described their lcov setup here:
https://wiki.documentfoundation.org/Development/Lcov
New numbers are lower now as we count in all the files never loaded which
decreases our percentages.
Overall coverage rate:
lines......: 30.2% (65119 of 215841 lines)
functions..: 34.0% (6361 of 18733 functions)
branches...: 23.6% (35627 of 151096 branches)
This has been a long standing issue and I finally figured out the details to
get this working. Since we started with coverage there always have been some
problems to get branch coverage work (problems with older gcc versions, lcov
not taking them into account, etc)
The last detail that made me go nuts was that in my lcov version (1.10) there
is a bug which leads to geninfo not applying the config file and thus not
enabling the branch coverage like I defined in the config. I added the
--rc option to work around this case.
In my local run I get this now from lcov-check:
Overall coverage rate:
lines......: 35.5% (65814 of 185169 lines)
functions..: 44.6% (7661 of 17195 functions)
branches...: 22.7% (31492 of 138942 branches)
So we have 22.7% branch coverage right now.
The vivid followers of my QA mails will also see the difference in numbers for
line and function coverage if one comapres my local results and the one on
Jenkins. This is another long standing issue and I need to figure out these
details next. :)
Switch to use a lcov config file which geninfo_auto_base and remove hard coding
the base dir to src/lib. geninfo_auto_base is designed for a use case like
ours where we have several base dirs (lib, bin, tests, ...) and it detects them
automatically. This fixes failures in a coverage run where the file is simply
looked for in the wrong directory.
To configure efl sources with bindings to use in nodejs add ––with-js=nodejs in configure flags to generate node files
$ configure --with-js=nodejs
and compile normally with:
$ make
$ make install
To use, you have to require efl:
efl = require('efl')
The bindings is divided in two parts: generated and manually
written. The generation uses the Eolian library for parsing Eo files
and generate C++ code that is compiled against V8 interpreter library
to create a efl.node file that can be required in a node.js instance.
@feature
Summary:
This lib would be used in efl_network_websocket.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: cedric
Reviewed By: cedric
Differential Revision: https://phab.enlightenment.org/D3244
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
this fixes warnings about no efreet dbus session bus in non session
environments as brought up on the mailing lists with:
Subject: Re: [E-devel] [EGIT] [core/efl] master 01/01: edje: unset
efreet cache update flag to prevent dbus connections
this moves all of efreetd client and server to ecore ipc, with client
auto-launching efreetd if not found as a service and trying for up to
500ms to connect. efreetd times out on last connection or no
connections after 10sec so it wont hang around forever if not in use.
it seems to work in my testing, so let me know if there is an issue.
@fix
Summary:
Ecore_Buffer is abstraction of graphic buffer.
it supports backend of shm, x11_dri2 and x11_dri3 for now,
and this library also provides method to share buffers between processes.
Ecore_Buffer_Provider and Ecore_Buffer_Consumer is for this, sharing buffer.
provider draws something in to Ecore_Buffer, and consumer receives and displays it.
the binary, bq_mgr is a connection maker for buffer provider and consumer.
it can be included Enlightenment as a deamon later.
@feature
Test Plan:
1. Configure with --enable-ecore-buffer and --enable-always-build-examples to build examples.
2. Run bq_mgr, it connects consumer and provider.
3. Run ecore_buffer_provider_example and ecore_buffer_consumer_example
Reviewers: lsj119, gwanglim, cedric, zmike, jpeg, raster, devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2197
This reverts commit 35119e7bfd.
Reverted to bring make check back in a working state. Also the way we
want to handle a more modular testing needs discussion.
Currently make check runs tests of whole EFL.Enabled running
of tests of individual modules by make check-<modulename>
Signed-off-by: kabeer khan <kabeer.khan@samsung.com>
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
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.
Summary: Added cmake config files for Eio
Test Plan: install it and test it with a app with needs eio
Reviewers: cedric, tasn
Reviewed By: tasn
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2079
While we used different variation of mkdir -p all over we also had spots
where we did not use the option. This is one step in trying to make our
build system ready for parallel install. Using something like -j 10 even
for the install should help to speed up our jenkins jobs as well as distcheck.