With this commit I'm finally able to use -j10 for make install on my machine.
During install libtool does some relinking which can result in to broken linking
if the dependencies are not handled correctly. Sadly automake has a problem with
the automatic dependency handling during install with LTLIBRARIES which we use
for all our modules. For the details please see this 4.5 years old bug report:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
We are now setting the dependency manually to force automake to the right decision
during install relinking.
Speed improvement itself is not that high (make -j 1 compared to -j10):
real 0m21.410s vs. real 0m17.066s
The bigger benefit is the unified use of MAKEOPTS or normal -j X in all our
build targets. I have seen quite some bug reports where -j was used for install
target when it was used in the build target. Last but not least it helps me to
unify some parts of the jenkins jobs and finally allows me to run distcheck
with -j Which uses install internally and failed before. Which goes down from
real 12m50.349s to real 5m52.120s.
Summary:
The new files for the shaders and he header file where not part of
EXTRA_DIST, so they where not found when running make distcheck.
Test Plan: just run make distcheck
Reviewers: cedric, q66
Reviewed By: q66
Subscribers: cedric, herdsman
Differential Revision: https://phab.enlightenment.org/D1998
Summary:
Add class and type Evas_3D_Callback like wrapper under smart object
Incapsulate Evas_3D_Callback in Evas_3D_Object
Add virtual function register and unregister in Evas_3D_Object
Add function evas_3d_callback_call
Add callbacks clicked and collision for Evas_3D_Node
@feature
Reviewers: raster, Hermet, cedric
Reviewed By: cedric
Subscribers: artem.popov, cedric
Differential Revision: https://phab.enlightenment.org/D1914
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
This native surface type is based on the tbm surface used for the tizen platform.
For the software_x11 backend, image data is retrieved from tbm surface
and color format converted appropriately.
This will only work when libtbm.so is present in the system.
@feature
Test Plan: Local tests
Reviewers: raster, cedric, jpeg, Hermet
Subscribers: wonsik, cedric
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
Summary:
implement native surface set for EVAS_NATIVE_SURFACE_X11 type
on software_x11 backend.
@feature
Test Plan: local tests on PC
Reviewers: jpeg, cedric, raster, Hermet
Subscribers: wonsik, cedric
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
Summary:
This native surface type is based on the tbm surface used for the tizen platform.
EGL_TIZEN_image_native_surface EGL extension is used to map
tbm surface to an egl image
@feature
Reviewers: raster, cedric, jpeg
Subscribers: cedric, wonsik
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
Here are only 3 very basic test cases.
One is a dumb set/get to check that image objects can
be passed as clippers.
The other one is a pixel verification test with extremely
basic data (NEAREST scaling and just rectangles). It also
compares text clipping and masking.
The last one performs a very basic verification that masks
of masks work.
This reverts commit df3958bb89.
This is getting reverted because it broke building of Enlightenment. E
requires the Evas_Engine_Buffer header file for drawing mouse cursor
using the buffer engine.
Those really are internals shared between ecore and evas.
Considering ecore & evas are just part of EFL, and expedite
now doesn't even rely on these headers anymore, we can safely
remove them from the dist packages.
This will allow us to break this seemingly internal API/ABI.
Summary:
Until now, it was necessary to set global LDFLAGS and CFLAGS to allow
compiling (and linking) engines using OpenGL.
gl_generic used to complained about missing headers or unkown libraries.
A problem on OSX is that there is CGL (Apple's Core OpenGL) on which the whole system
relies on and GLX, when X11 is installed; and they cohabit together.
When gl_cocoa is enabled, gl_generic is now linked against CGL.
When it is not, gl_generic is compiled with and linked against GLX as a fallback.
@fix
Test Plan:
With --enable-cocoa: software_x11, opengl_x11 and opengl_cocoa are working as expected.
With --disable-cocoa: software_x11 and opengl_x11 are also working as expected.
No compiling nor linking problems have been issued.
Reviewers: cedric, raster, raoulh
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1723
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
.ply format is important for relation blender and EFl, because in blender exist only two mesh export API: bpy.ops.import_mesh.ply and bpy.ops.import_mesh.stl. One of them is necessary for .edc 3D generator. Which I writing now.
Sorry, it isn't like image loader. Refactoring of import/export will be soon.
Reviewers: Oleksander, artem.popov, Hermet, raster, cedric
Reviewed By: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1544
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Some shader files (shd) were not included in EXTRA_DIST. This didn't break
the build because the .x file was correctly generated.
I guess the missing files in previous releases also had no impact because
the .h files would be generated and shipped.
Also generate the enum automagically. New shaders need to be added
to Makefile_Evas.am.
Like the evas drm engine the evas gl_drm engine now depends on eeze for
backlight. Make sure it is setup to find eeze like the drm engine already
does.
I have not been able to reproduce this myself but I have seen a build log where
the binary tries to link to libeo and fails due to the missing file.
A similar problem was "fixed" in 0e4b847deb, but
this really makes me wonder where the linking against eo comes from for cserve2
which is not using eo as far as I can see.
Various files form the tgv and 3d tests have been missing in EXTRA_DIST
and thus failing make distcheck. On the other hand we had duplicates in
the list. Clear this all up.
Add version param to context_create.
Add support for 1.1 contexts in the GL_X11 engine, and checks
for version in all other engines (return NULL).
Add API wrappers for all OpenGL-ES 1.1 APIs (normal and debug
modes).
Summary: The first version of .eet format is added. All changes due to discussion in D1307 are done.
Reviewers: artem.popov, se.osadchy, reutskiy.v.v, Hermet, raster, cedric, Oleksander
@feature
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1477
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This cleans up a lot of the build system. This makes everything
consistent, clean, less redundant and also fixes the issue of make clean
not cleaning up generated files.
Summary: The first version of .eet format is added.
Reviewers: Hermet, raster, cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1307
While we are likely will keep the embedded copy for a while to avoid a really
new dependency we allow now to use the external liblz4. You need at least
revision r120 and a package that ships the pc file for it.
Personally I would like to get rid of it rather sooner than later due to the
security implications and a bunch of code we ship but have no idea about.
Reality is that it will need some time until this new lib is actually
packaged and shipped with releases for a a majority of people.
This patch was co-worked with Doug Newgard <scimmia22@outlook.com>
For some reason dummy links against libeo but doesn't depend on it.
I have no idea what dummy_slave is and why it behaves in such an odd way.
Maybe there's even a more serious issue somewhere, but for now, this seems
to fix build.
Summary: This is the first step to introduce a gl-drm backend.
Test Plan: "ecore evas" create with ecore_evas_gl_drm_new(). It creates "ecore evas" with gl_drm evas backend.
@feature
Reviewers: raster, Hermet, cedric, devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1187
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
@fix
Segfault in wayland_egl engine is casused by illegal library linking.
Fix this by linking to GLESv2 and EGL libraries.
Test Plan: N/A
Reviewers: devilhorns, raster, cedric, Hermet
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1332
Summary:
This patch fixes following two problems:
1. libevas.so library has a dependency with ecore_drm if '--enable-drm' configure
option is given. This problem is due to 'EFL_INTERNAL_DEPEND_PKG([EVAS], [ecore-drm])'
in m4/evas_check_engine.m4 file. A dependency with ecore_drm should be moved to evas
drm engine not libevas.so. And also this macro makes an error while installation of evas.
$ make uninstall; ./configure --enable-drm; make && make install
2. missing ecore_drm dependency for evas drm engine.
USE_ECORE_DRM_LIBS macro should be used for building evas drm engine with ecore_drm
library. ECORE_DRM_LIBS macro doesn't have 'libecore_drm.la'. It is used for building
ecore_drm library.
@fix
Fixes T1473
Test Plan:
1. Remove EFL libraries in installation path: $ make uninstall
2. Configure with --enable-drm: $ ./autogen.sh --enable-drm
3. $ make && make install
4. Check module.so of evas drm engine whether it has a library dependency with ecore_drm
$ readelf -a $EFL_GIT/src/modules/evas/engines/drm/.libs/module.so | grep NEEDED
$ readelf -a $INSTALL_PATH/lib/evas/modules/engines/drm/v-1.11/module.so | grep NEEDED
Reviewers: stefan_schmidt, devilhorns, raster
Subscribers: cedric, torori
Differential Revision: https://phab.enlightenment.org/D1271
I'm not 100% sure this header is internal, but it depends on internal
headers, so it should either be internal or massively re-worked.
Anyhow, it has no business being installed until the includes are
fixed.