kimcinoo
/
efl
forked from enlightenment/efl
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
efl/src/Makefile_Evas.am

2837 lines
117 KiB
Plaintext
Raw Normal View History

merge: and now Evas 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
2012-11-04 03:51:42 -08:00
### Library
evas build: fix installation paths for new gesture stuff EFL-using things wouldn't build after addition of the new gesture stuff because gesture headers would get installed into the $PREFIX/evas-1/canvas instead of $PREFIX/evas-1/gesture directory and Evas_Eo.h is including headers from the gesture/ directory. This fixes the problem by installing the headers into their correct location. Spanks go to @jpeg for not reviewing things properly.
2017-10-19 06:59:16 -07:00
evas_canvas_eolian_pub_files = \
evas: Rename Evas.Object to Efl.Canvas.Object One step closer to make the EO inheritance tree look like it's all Efl.
2016-06-20 21:26:15 -07:00
lib/evas/canvas/efl_canvas_object.eo \
evas: add new event_grabber smart-ish object adding an "event rect" is a common use case for rectangles, but I needed a smarter event rect so I sent one off to school and it came back like this. an event_grabber is a smart object which functions like a normal event rect which has color(0,0,0,0), but with an important difference: it can have smart members. event propagation works differently for an event_grabber: normal: event -> layer -> smart(obj1,obj2,obj3) ->(?) other objects in this case, obj1,obj2,obj3 are all "inside" the smart object and their stacking will always be considered as being inside the smart object. rendering is also tied to the smart object in this case, as is clipping. an event which reaches a smart object will be sent to the objects inside, and then may continue through the smart object if there are no objects which block repeating. event_grabber: event -> layer -> event_grabber -> obj1,obj2,obj3 -> STOP in this case, obj1,obj2,obj3 are unmodified after being added to the event_grabber and can be stacked, rendered, and clipped completely independently of the event_grabber. the event_grabber is considered an "event_parent" for this case. member objects are not "inside" the event_grabber, and they are unable to receive events on their own. instead, the event_grabber, which must be stacked above all its members, receives events and propagates them top->down through its member objects. if none of the member objects block the repeat of an event then the event will still be blocked from further propagation past the event_grabber. object lifetimes are independent of the event_grabber; deleting the event_grabber has no effect on its members. @feature
2017-06-09 17:16:08 -07:00
lib/evas/canvas/efl_canvas_object_event_grabber.eo \
evas: move Evas_Polygon to become Efl_Canvas_Polygon. TODO: add support for 2 points (aka line).
2016-03-14 14:59:33 -07:00
lib/evas/canvas/efl_canvas_polygon.eo \
Evas: Rename Evas.Rectangle as Efl.Canvas.Rectangle
2016-06-02 02:55:51 -07:00
lib/evas/canvas/efl_canvas_rectangle.eo \
Canvas text: introduce new text object The implementation depends on creating different code paths from the now-legacy behavior of text appending. The annotation system introduced in this commit replaces the current way of applying formats on text. Up until now it has been quite a hassle for the user to control the formats, as it required keeping track of the format positions with an opener and closer formats almost every time (with the exception of own-closing formats). The combination of Efl.Text API along with the Efl.Canvas.Text annotation API essentially replaces the capabilities of the old format. There is additional annotation API to allow more control, so be sure to check the documentation/.eo files and the wiki page of Efl.Canvas.Text. The style API now accepts actual strings of format style. There is not longer need to instantiate as style with style_new() followed later by style_free(). @feature
2016-05-24 06:11:03 -07:00
lib/evas/canvas/efl_canvas_text.eo \
Canvas image: add Efl.Canvas.Text.Factory + use in Ui.Text This interface has a simple 'create' method to create Efl.Canvas.Object given a key. This is used higher-up in Ui.Text in the next commit. Ui text: add ability to set item factories Added API to set an item factory object. This is similar to the previous item providers (that worked with callbacks). You instantiate a factory object and set it on the Ui.Text object. Each factory implements the "create" method from Efl.Canvas.Text.Item_Factory. This also includes 3 public factories (Image, Emoticon and Fallback): - Image factory: creates images from added entries (key strings) - Emoticon factory: creates emoticons by querying the theme - Fallback: creates image, then falls back to emoticon If no factory is set, then the fallback (internal) factory is used. See the added "Ui.text Item Factory" test in elementary_test for an example of usage. @feature
2017-11-09 07:53:20 -08:00
lib/evas/canvas/efl_canvas_text_factory.eo \
Evas: Rename smart object into Efl.Canvas.Group
2016-06-17 01:26:08 -07:00
lib/evas/canvas/efl_canvas_group.eo \
Evas: Rename Evas.Image into Efl.Canvas.Image.Internal Make it abstract. And add Evas.Image as a legacy-only class.
2016-06-09 01:30:05 -07:00
lib/evas/canvas/efl_canvas_image_internal.eo \
evas: change interface evas_3d to evas_canvas3d Summary: Regard to https://phab.enlightenment.org/T2479 it is need for right generation Eolian files Reviewers: cedric Subscribers: cedric, tasn Differential Revision: https://phab.enlightenment.org/D2711 Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
2015-06-17 07:31:14 -07:00
lib/evas/canvas/evas_canvas3d_camera.eo\
lib/evas/canvas/evas_canvas3d_texture.eo\
lib/evas/canvas/evas_canvas3d_material.eo\
lib/evas/canvas/evas_canvas3d_light.eo\
lib/evas/canvas/evas_canvas3d_mesh.eo\
lib/evas/canvas/evas_canvas3d_primitive.eo\
lib/evas/canvas/evas_canvas3d_node.eo\
lib/evas/canvas/evas_canvas3d_scene.eo\
lib/evas/canvas/evas_canvas3d_object.eo \
evas/vg: renamed the evas_vg class to efl_canvas_vg Reviewers: jpeg Subscribers: jenkins, cedric Differential Revision: https://phab.enlightenment.org/D5357
2017-10-23 23:19:52 -07:00
lib/evas/canvas/efl_canvas_vg.eo \
Efl vg: Remove the no longer needed .Base hack.
2016-05-11 05:13:27 -07:00
lib/evas/canvas/efl_vg.eo \
evas: move Evas.VG_* to Efl.VG.* This also introduce legacy API for all of them.
2015-04-03 07:30:59 -07:00
lib/evas/canvas/efl_vg_container.eo \
lib/evas/canvas/efl_vg_shape.eo \
lib/evas/canvas/efl_vg_gradient.eo \
lib/evas/canvas/efl_vg_gradient_radial.eo \
Evas filters: EO-ify the filters API This creates the new interface Efl.Gfx.Filter And the implementation is a mixin (evas_filter_mixin.c): Evas.Filter All the filter rendering code has now been moved to this new file. TODO: Merge image filtering.
2015-06-17 00:26:30 -07:00
lib/evas/canvas/efl_vg_gradient_linear.eo \
Evas.Image: Create Efl.Canvas.Image for file & data images This replaces standard Evas_Object_Image when it is used "normally", ie. it's an image from a file or from a pixel buffer. All other APIs (proxy, snapshot, 3d, gl, ...) are disabled on this object. Also, reduce number of failing calls when the object is not a legacy object, but a legacy function is called. This is because a lot of image APIs are called internally using the legacy APIs, often in order to reset the state of the image object (eg. set file to NULL, etc...)
2016-03-16 03:37:04 -07:00
lib/evas/canvas/efl_canvas_image.eo \
Evas.Image: Add new classes Snapshot and Proxy Efl.Canvas.Snapshot and Efl.Canvas.Proxy are specialized classes previously implemented as features of Evas.Image. Note: this half of the work, as I suffered from a bad merge and rebase with my work branch on top of master.
2016-03-14 03:10:54 -07:00
lib/evas/canvas/efl_canvas_snapshot.eo \
lib/evas/canvas/efl_canvas_proxy.eo \
Evas: Move 3d to Efl.Canvas.Scene3d This still seems a bit redondant with the underlying Evas.Canvas3d.Scene class.
2016-03-07 21:11:07 -08:00
lib/evas/canvas/efl_canvas_scene3d.eo \
Evas.Image: Move native surfaces to Efl.Canvas.Surface X11, TBM and Wayland support are implemented for now.
2016-03-08 23:21:08 -08:00
lib/evas/canvas/efl_canvas_surface.eo \
lib/evas/canvas/efl_canvas_surface_tbm.eo \
lib/evas/canvas/efl_canvas_surface_x11.eo \
lib/evas/canvas/efl_canvas_surface_wayland.eo \
Evas: Rename Evas.Filter to Efl.Canvas.Filter.Internal Trying to hide the name Evas from the public EO API...
2016-06-09 23:55:28 -07:00
lib/evas/canvas/efl_canvas_filter_internal.eo \
efl: Rename Efl.Event.XX to Efl.Input.XX This removes: Efl.Event interface And renames: Efl.Event.Input -> Efl.Input.Event Efl.Event -> Efl.Input.Event (merged) Efl.Event.Pointer -> Efl.Input.Pointer Efl.Event.Key -> Efl.Input.Key Efl.Event.Hold -> Efl.Input.Hold This also moves some interfaces from efl/ to evas/ where they belong better. This allows renaming Eo_Event to Efl_Event.
2016-08-25 03:20:10 -07:00
lib/evas/canvas/efl_input_state.eo \
lib/evas/canvas/efl_input_interface.eo \
lib/evas/canvas/efl_input_event.eo \
lib/evas/canvas/efl_input_key.eo \
lib/evas/canvas/efl_input_pointer.eo \
lib/evas/canvas/efl_input_hold.eo \
Evas: Add Focus event type.
2016-11-17 11:29:58 -08:00
lib/evas/canvas/efl_input_focus.eo \
evas: Move map to a separate mixin Evas map is not translated to proper eo apis yet. Efl.Canvas.Map will be a mixin implementing the evas map API in a bindable API.
2016-06-27 22:12:17 -07:00
lib/evas/canvas/efl_gfx_map.eo \
efl_animation: Add efl_animation Efl.Animation is a class which contains basic properties of animation for Efl.Canvas.Object.
2017-08-24 04:45:52 -07:00
lib/evas/canvas/efl_animation.eo \
efl_animation: Add alpha animation
2017-08-24 18:14:51 -07:00
lib/evas/canvas/efl_animation_alpha.eo \
efl_animation: Add rotate animation
2017-08-24 19:10:58 -07:00
lib/evas/canvas/efl_animation_rotate.eo \
efl_animation: Add scale animation
2017-08-24 19:34:28 -07:00
lib/evas/canvas/efl_animation_scale.eo \
efl_animation: Add translate animation
2017-08-24 21:37:12 -07:00
lib/evas/canvas/efl_animation_translate.eo \
efl_animation: Add group animation Efl.Animation.Group is an abstract class which provides methods for group animations such as parallel and sequential group animations.
2017-08-25 01:08:59 -07:00
lib/evas/canvas/efl_animation_group.eo \
efl_animation: Add parallel group animation and object Efl.Animation.Group.Parallel is a class for animations started in parallel. Efl.Animation.Object.Group.Parallel is a class which provides methods for an object of Efl.Animation.Group.Parallel. The objects added into the parallel group animation object start in parallel.
2017-08-25 01:54:29 -07:00
lib/evas/canvas/efl_animation_group_parallel.eo \
efl_animation: Add sequential group animation and object Efl.Animation.Group.Sequential is a class for animations started in sequence. Efl.Animation.Object.Group.Sequential is a class which provides methods for an object of Efl.Animation.Group.Sequential. The objects added into the sequential group animation object start in sequence.
2017-08-29 20:08:41 -07:00
lib/evas/canvas/efl_animation_group_sequential.eo \
efl_playable: split Efl.Player interface to Efl.Playable interface Summary: Efl.Player interface simply provides play functions, but another interface which indicates Efl.Player will play is also needed. Test Plan: Run elementary_test->Efl.Animation tests Reviewers: woohyun, conr2d, Jaehyun_Cho, jpeg, cedric Differential Revision: https://phab.enlightenment.org/D5662
2018-01-16 03:31:15 -08:00
lib/evas/canvas/efl_animation_player.eo \
evas build: fix installation paths for new gesture stuff EFL-using things wouldn't build after addition of the new gesture stuff because gesture headers would get installed into the $PREFIX/evas-1/canvas instead of $PREFIX/evas-1/gesture directory and Evas_Eo.h is including headers from the gesture/ directory. This fixes the problem by installing the headers into their correct location. Spanks go to @jpeg for not reviewing things properly.
2017-10-19 06:59:16 -07:00
$(NULL)
evas_gesture_eolian_pub_files = \
evas/gesture: Added Eo classes for evas gesture framework.
2017-09-18 23:03:42 -07:00
lib/evas/gesture/efl_gesture_touch.eo \
lib/evas/gesture/efl_gesture.eo \
lib/evas/gesture/efl_gesture_tap.eo \
evas/gesture: Added long_tap gesture to gesture framework
2017-09-20 18:23:18 -07:00
lib/evas/gesture/efl_gesture_long_tap.eo \
evas/gesture: Added Eo classes for evas gesture framework.
2017-09-18 23:03:42 -07:00
lib/evas/gesture/efl_gesture_recognizer.eo \
lib/evas/gesture/efl_gesture_manager.eo \
Evas: Fix make check after ector gl work evas_ector is not meant to be public so remove it from the C++ bindings
2016-01-03 19:21:03 -08:00
$(NULL)
evas: actually we still do need those header for the legacy API
2016-03-21 16:03:36 -07:00
evas_eolian_legacy_files = \
evas: Move evas_canvas.eo to legacy-only This isn't meant to be installed. The canvas API in EO is based around the interfaces Efl.Canvas and the widget Efl.Ui.Win. Anything else is not EO (eg: ecore_evas, evas, ...) Note: evas_canvas3d is the last remaining thing that is installed along EO files, but those are all beta APIs.
2017-10-31 00:36:32 -07:00
lib/evas/canvas/evas_canvas.eo \
evas: disable installation of no longer supported Eo object for EFL 2.0.
2016-03-21 15:01:36 -07:00
lib/evas/canvas/evas_line.eo \
lib/evas/canvas/evas_table.eo \
lib/evas/canvas/evas_grid.eo \
lib/evas/canvas/evas_box.eo\
lib/evas/canvas/evas_text.eo \
lib/evas/canvas/evas_textgrid.eo \
Evas: Rename Evas.Image into Efl.Canvas.Image.Internal Make it abstract. And add Evas.Image as a legacy-only class.
2016-06-09 01:30:05 -07:00
lib/evas/canvas/evas_image.eo \
Evas filters: EO-ify the filters API This creates the new interface Efl.Gfx.Filter And the implementation is a mixin (evas_filter_mixin.c): Evas.Filter All the filter rendering code has now been moved to this new file. TODO: Merge image filtering.
2015-06-17 00:26:30 -07:00
$(NULL)
Build system: Clean up the generation of sources from eolian. 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.
2014-10-02 08:52:45 -07:00
evas build: fix installation paths for new gesture stuff EFL-using things wouldn't build after addition of the new gesture stuff because gesture headers would get installed into the $PREFIX/evas-1/canvas instead of $PREFIX/evas-1/gesture directory and Evas_Eo.h is including headers from the gesture/ directory. This fixes the problem by installing the headers into their correct location. Spanks go to @jpeg for not reviewing things properly.
2017-10-19 06:59:16 -07:00
evas_canvas_eolian_priv_files = \
lib/evas/include/evas_ector_buffer.eo
evas_gesture_eolian_priv_files = \
evas/gesture: Added long_tap gesture to gesture framework
2017-09-20 18:23:18 -07:00
lib/evas/gesture/efl_gesture_recognizer_tap.eo \
lib/evas/gesture/efl_gesture_recognizer_long_tap.eo
evas: actually we still do need those header for the legacy API
2016-03-21 16:03:36 -07:00
evas build: fix installation paths for new gesture stuff EFL-using things wouldn't build after addition of the new gesture stuff because gesture headers would get installed into the $PREFIX/evas-1/canvas instead of $PREFIX/evas-1/gesture directory and Evas_Eo.h is including headers from the gesture/ directory. This fixes the problem by installing the headers into their correct location. Spanks go to @jpeg for not reviewing things properly.
2017-10-19 06:59:16 -07:00
evas_canvas_eolian_type_files = \
efl_animation: Add efl_animation Efl.Animation is a class which contains basic properties of animation for Efl.Canvas.Object.
2017-08-24 04:45:52 -07:00
lib/evas/canvas/evas_canvas3d_types.eot \
evas build: fix installation paths for new gesture stuff EFL-using things wouldn't build after addition of the new gesture stuff because gesture headers would get installed into the $PREFIX/evas-1/canvas instead of $PREFIX/evas-1/gesture directory and Evas_Eo.h is including headers from the gesture/ directory. This fixes the problem by installing the headers into their correct location. Spanks go to @jpeg for not reviewing things properly.
2017-10-19 06:59:16 -07:00
lib/evas/canvas/efl_animation_types.eot
evas_gesture_eolian_type_files = \
evas/gesture: Added Eo classes for evas gesture framework.
2017-09-18 23:03:42 -07:00
lib/evas/gesture/efl_gesture_types.eot
evas build: fix installation paths for new gesture stuff EFL-using things wouldn't build after addition of the new gesture stuff because gesture headers would get installed into the $PREFIX/evas-1/canvas instead of $PREFIX/evas-1/gesture directory and Evas_Eo.h is including headers from the gesture/ directory. This fixes the problem by installing the headers into their correct location. Spanks go to @jpeg for not reviewing things properly.
2017-10-19 06:59:16 -07:00
evas_canvas_eolian_priv_c = $(evas_canvas_eolian_priv_files:%.eo=%.eo.c)
evas_canvas_eolian_priv_h = $(evas_canvas_eolian_priv_files:%.eo=%.eo.h) \
$(evas_eolian_legacy_files:%.eo=%.eo.h)
evas_gesture_eolian_priv_c = $(evas_gesture_eolian_priv_files:%.eo=%.eo.c)
evas_gesture_eolian_priv_h = $(evas_gesture_eolian_priv_files:%.eo=%.eo.h)
Evas: Add a general evas types header.
2015-05-29 06:46:02 -07:00
evas build: fix installation paths for new gesture stuff EFL-using things wouldn't build after addition of the new gesture stuff because gesture headers would get installed into the $PREFIX/evas-1/canvas instead of $PREFIX/evas-1/gesture directory and Evas_Eo.h is including headers from the gesture/ directory. This fixes the problem by installing the headers into their correct location. Spanks go to @jpeg for not reviewing things properly.
2017-10-19 06:59:16 -07:00
evas_canvas_eolian_pub_c = $(evas_canvas_eolian_pub_files:%.eo=%.eo.c)
evas_canvas_eolian_pub_h = $(evas_canvas_eolian_pub_files:%.eo=%.eo.h) \
$(evas_canvas_eolian_pub_files:%.eo=%.eo.legacy.h) \
$(evas_canvas_eolian_type_files:%.eot=%.eot.h)
Evas: Do not install evas_ector_buffer This is an internal API, should not be installed.
2016-01-05 23:26:01 -08:00
evas build: fix installation paths for new gesture stuff EFL-using things wouldn't build after addition of the new gesture stuff because gesture headers would get installed into the $PREFIX/evas-1/canvas instead of $PREFIX/evas-1/gesture directory and Evas_Eo.h is including headers from the gesture/ directory. This fixes the problem by installing the headers into their correct location. Spanks go to @jpeg for not reviewing things properly.
2017-10-19 06:59:16 -07:00
evas_gesture_eolian_pub_c = $(evas_gesture_eolian_pub_files:%.eo=%.eo.c)
evas_gesture_eolian_pub_h = $(evas_gesture_eolian_pub_files:%.eo=%.eo.h) \
$(evas_gesture_eolian_pub_files:%.eo=%.eo.legacy.h) \
$(evas_gesture_eolian_type_files:%.eot=%.eot.h)
Evas: Do not install evas_ector_buffer This is an internal API, should not be installed.
2016-01-05 23:26:01 -08:00
evas: actually we still do need those header for the legacy API
2016-03-21 16:03:36 -07:00
evas_eolian_legacy_c = $(evas_eolian_legacy_files:%.eo=%.eo.c)
evas_eolian_legacy_h = $(evas_eolian_legacy_files:%.eo=%.eo.legacy.h)
evas build: fix installation paths for new gesture stuff EFL-using things wouldn't build after addition of the new gesture stuff because gesture headers would get installed into the $PREFIX/evas-1/canvas instead of $PREFIX/evas-1/gesture directory and Evas_Eo.h is including headers from the gesture/ directory. This fixes the problem by installing the headers into their correct location. Spanks go to @jpeg for not reviewing things properly.
2017-10-19 06:59:16 -07:00
evas_eolian_files = $(evas_canvas_eolian_pub_files) \
$(evas_canvas_eolian_type_files) \
$(evas_gesture_eolian_pub_files) \
$(evas_gesture_eolian_type_files)
evas_eolian_internal_files = $(evas_canvas_eolian_priv_files) \
$(evas_gesture_eolian_priv_files) \
$(evas_eolian_legacy_files)
evas_eolian_c = $(evas_canvas_eolian_pub_c) $(evas_canvas_eolian_priv_c) \
$(evas_gesture_eolian_pub_c) $(evas_gesture_eolian_priv_c) \
$(evas_eolian_legacy_c)
evas_eolian_h = $(evas_canvas_eolian_pub_h) $(evas_canvas_eolian_priv_h) \
$(evas_gesture_eolian_pub_h) $(evas_gesture_eolian_priv_h) \
$(evas_eolian_legacy_h)
Build system: Clean up the generation of sources from eolian. 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.
2014-10-02 08:52:45 -07:00
Eolian: generation of the first Eo file. 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.com yossi.kantor@samsung.com
2014-03-05 03:54:39 -08:00
BUILT_SOURCES += \
Build system: Clean up the generation of sources from eolian. 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.
2014-10-02 08:52:45 -07:00
$(evas_eolian_c) \
$(evas_eolian_h)
Eolian: generation of the first Eo file. 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.com yossi.kantor@samsung.com
2014-03-05 03:54:39 -08:00
Eolian: Set eolian_flags in .pc files and ship .eo files.
2014-03-13 02:55:12 -07:00
evaseolianfilesdir = $(datadir)/eolian/include/evas-@VMAJ@
Evas: Fix the build... I hope I forgot to modify some lines. Of course randomness made things work for me.
2016-01-06 00:18:57 -08:00
evaseolianfiles_DATA = $(evas_eolian_files)
Evas_3D : Eolian change Conflicts: src/Makefile_Evas.am src/lib/evas/Evas_3D.h src/lib/evas/Evas_Eo.h
2014-04-14 03:03:47 -07:00
build: split EXTRA_DIST files in src/ off from DISTFILES and handle separately This is again to avoid the "Argument list too long" error we are hitting more and more now. Given we just merged elementary, emotion generic players, evas generic loaders and elm_code it is not surprising we are hitting it again. This time the number of files being hold in DISTFILES has just grown to big so a make dist was no longer possible. If one looks at what the DISTFILES variable from automake holds you can image it grows a lot with all the source files plus generated files we have in tree now. DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) To cut off a big chunk but still keep all the other automagic in place for SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle the files in a dist-hook now. Another thing to note here is that this also only happens as we have the one big Makefile with includes. If we go back to per directory Makefiles this problem should vanish as well. In any case we need a solution for 1.18 now and this is what I have to offer. If you have a cleaner solution in mind feel welcome to test it out and if everything we need keeps working (make, make examples, make check, make benchmark, make dist and make distcheck) go ahead.
2016-06-08 01:26:06 -07:00
EXTRA_DIST2 += \
evas: actually we still do need those header for the legacy API
2016-03-21 16:03:36 -07:00
$(evaseolianfiles_DATA) \
evas build: fix installation paths for new gesture stuff EFL-using things wouldn't build after addition of the new gesture stuff because gesture headers would get installed into the $PREFIX/evas-1/canvas instead of $PREFIX/evas-1/gesture directory and Evas_Eo.h is including headers from the gesture/ directory. This fixes the problem by installing the headers into their correct location. Spanks go to @jpeg for not reviewing things properly.
2017-10-19 06:59:16 -07:00
$(evas_eolian_internal_files)
Eolian: Set eolian_flags in .pc files and ship .eo files.
2014-03-13 02:55:12 -07:00
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib_LTLIBRARIES += lib/evas/libevas.la
installed_evasmainheadersdir = $(includedir)/evas-@VMAJ@
Evas: Split Evas headers Now, Evas.h includes three new files: - Evas_Eo.h: Eo API functions (functions defines, enums, base id). - Evas_Legacy.h: contains the API functions related to objects - Evas_Common.h: common data (structs, enums...) + functions not related to objects. This phase is needed for the EFL 1.8 release to disable Eo APIs if we consider it is not enough mature to be used by applications.
2013-04-24 12:56:24 -07:00
dist_installed_evasmainheaders_DATA = \
lib/evas/Evas.h \
evas: Keep sane name for public header Evas_Common.h should be used for the public header, and rather rename evas_common.h internal header to another name. Sa: Evas_Common_Header.h -> Evas_Common.h evas_common.h -> evas_common_private.h Shouldn't have both Evas_Common.h and evas_common.h because of case insensitive filesystems.
2013-06-20 03:53:29 -07:00
lib/evas/Evas_Common.h \
Evas: Split Evas headers Now, Evas.h includes three new files: - Evas_Eo.h: Eo API functions (functions defines, enums, base id). - Evas_Legacy.h: contains the API functions related to objects - Evas_Common.h: common data (structs, enums...) + functions not related to objects. This phase is needed for the EFL 1.8 release to disable Eo APIs if we consider it is not enough mature to be used by applications.
2013-04-24 12:56:24 -07:00
lib/evas/Evas_Eo.h \
lib/evas/Evas_Legacy.h \
evas: Make Evas_Loader API public.
2013-05-06 18:50:57 -07:00
lib/evas/Evas_GL.h \
Fix evas compilation and installation.
2014-03-06 01:13:38 -08:00
lib/evas/Evas_Loader.h
installed_evascanvasheadersdir = $(includedir)/evas-@VMAJ@/canvas
evas build: fix installation paths for new gesture stuff EFL-using things wouldn't build after addition of the new gesture stuff because gesture headers would get installed into the $PREFIX/evas-1/canvas instead of $PREFIX/evas-1/gesture directory and Evas_Eo.h is including headers from the gesture/ directory. This fixes the problem by installing the headers into their correct location. Spanks go to @jpeg for not reviewing things properly.
2017-10-19 06:59:16 -07:00
nodist_installed_evascanvasheaders_DATA = $(evas_canvas_eolian_pub_h) \
$(evas_eolian_legacy_h)
Canvas Text: continue porting api and fixup bugs Also: This merges style user and normal style into a list with precedence. This allows for more flexibility while keeping the API clean. @feature
2016-06-07 10:16:34 -07:00
dist_installed_evascanvasheaders_DATA = lib/evas/canvas/evas_textblock_legacy.h
evas build: fix installation paths for new gesture stuff EFL-using things wouldn't build after addition of the new gesture stuff because gesture headers would get installed into the $PREFIX/evas-1/canvas instead of $PREFIX/evas-1/gesture directory and Evas_Eo.h is including headers from the gesture/ directory. This fixes the problem by installing the headers into their correct location. Spanks go to @jpeg for not reviewing things properly.
2017-10-19 06:59:16 -07:00
installed_evasgestureheadersdir = $(includedir)/evas-@VMAJ@/gesture
nodist_installed_evasgestureheaders_DATA = $(evas_gesture_eolian_pub_h)
elementary: enable compilation of binary.
2016-03-23 20:55:38 -07:00
noinst_DATA += $(evas_eolian_priv_h)
Eolian: Legacy integration of Evas Object
2014-04-02 06:15:28 -07:00
elementary: enable compilation of binary.
2016-03-23 20:55:38 -07:00
noinst_HEADERS += \
evas: move Efl_Canvas_Output to be an internal only API.
2017-04-13 15:25:29 -07:00
lib/evas/Evas_Internal.h \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib/evas/include/evas_inline.x \
lib/evas/include/evas_private.h \
lib/evas/include/evas_options.h \
lib/evas/include/evas_macros.h \
lib/evas/include/evas_mmx.h \
evas: Keep sane name for public header Evas_Common.h should be used for the public header, and rather rename evas_common.h internal header to another name. Sa: Evas_Common_Header.h -> Evas_Common.h evas_common.h -> evas_common_private.h Shouldn't have both Evas_Common.h and evas_common.h because of case insensitive filesystems.
2013-06-20 03:53:29 -07:00
lib/evas/include/evas_common_private.h \
fix distckeck for filter
2014-02-07 18:36:06 -08:00
lib/evas/include/evas_blend_ops.h \
evas: fix make distcheck.
2015-04-03 07:33:53 -07:00
lib/evas/include/evas_filter.h \
evas: forgotten header needed for make dist.
2015-05-31 05:57:48 -07:00
lib/evas/canvas/evas_vg_private.h \
Evas.Image: Move native surfaces to Efl.Canvas.Surface X11, TBM and Wayland support are implemented for now.
2016-03-08 23:21:08 -08:00
lib/evas/canvas/evas_image_private.h \
evas: move Efl_Canvas_Polygon_Data struct to separate header
2016-05-05 07:27:50 -07:00
lib/evas/canvas/evas_polygon_private.h \
Evas.Image: Move native surfaces to Efl.Canvas.Surface X11, TBM and Wayland support are implemented for now.
2016-03-08 23:21:08 -08:00
lib/evas/canvas/efl_canvas_surface.h \
efl_animation: Add efl_animation Efl.Animation is a class which contains basic properties of animation for Efl.Canvas.Object.
2017-08-24 04:45:52 -07:00
lib/evas/common3d/primitives/primitive_common.h \
efl_animation: Add animation object Efl.Animation.Object is a class which starts or cancels animation. Efl.Animation.Object instance is created by Efl.Animation instance. So Efl.Animation.Object instance contains animation properties from Efl.animation instance. Animation properties are set by using Efl.Animation instance and the animation is started or cancelled by using Efl.Animation.Object.
2017-08-24 06:34:13 -07:00
lib/evas/canvas/efl_animation_private.h \
efl_animation: Add alpha animation
2017-08-24 18:14:51 -07:00
lib/evas/canvas/efl_animation_alpha_private.h \
efl_animation: Add rotate animation
2017-08-24 19:10:58 -07:00
lib/evas/canvas/efl_animation_rotate_private.h \
efl_animation: Add scale animation
2017-08-24 19:34:28 -07:00
lib/evas/canvas/efl_animation_scale_private.h \
efl_animation: Add translate animation
2017-08-24 21:37:12 -07:00
lib/evas/canvas/efl_animation_translate_private.h \
efl_animation: Add group animation Efl.Animation.Group is an abstract class which provides methods for group animations such as parallel and sequential group animations.
2017-08-25 01:08:59 -07:00
lib/evas/canvas/efl_animation_group_private.h \
efl_animation: Add parallel group animation and object Efl.Animation.Group.Parallel is a class for animations started in parallel. Efl.Animation.Object.Group.Parallel is a class which provides methods for an object of Efl.Animation.Group.Parallel. The objects added into the parallel group animation object start in parallel.
2017-08-25 01:54:29 -07:00
lib/evas/canvas/efl_animation_group_parallel_private.h \
efl_animation: Add sequential group animation and object Efl.Animation.Group.Sequential is a class for animations started in sequence. Efl.Animation.Object.Group.Sequential is a class which provides methods for an object of Efl.Animation.Group.Sequential. The objects added into the sequential group animation object start in sequence.
2017-08-29 20:08:41 -07:00
lib/evas/canvas/efl_animation_group_sequential_private.h \
efl_playable: split Efl.Player interface to Efl.Playable interface Summary: Efl.Player interface simply provides play functions, but another interface which indicates Efl.Player will play is also needed. Test Plan: Run elementary_test->Efl.Animation tests Reviewers: woohyun, conr2d, Jaehyun_Cho, jpeg, cedric Differential Revision: https://phab.enlightenment.org/D5662
2018-01-16 03:31:15 -08:00
lib/evas/canvas/efl_animation_player_private.h \
evas: move evas_stack.c -> evas_stack.x this file contains canvas methods which should be subject to compiler type checking, requiring that they be included in the file which contains the eolian generated code
2018-02-14 18:14:51 -08:00
lib/evas/canvas/evas_stack.x \
evas/gesture: Added gesture_private header file.
2017-09-18 23:09:49 -07:00
lib/evas/gesture/efl_gesture_private.h
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
Revert "Static deps: Move unibreak to be an external dep." Apparently the Debian package, while up to date, for some reason does not ship the .pc file (according to q66). According to Stefan, Fedora doesn't even have libunibreak, but only the previous naming and old version. Will have to wait a few years more. :( This reverts commit a2a9f33802a3923c1469789f66d5fdab1eaea943.
2015-05-07 02:40:57 -07:00
# Linebreak
noinst_HEADERS += \
Static deps unibreak: update to what will soon be version 3. Version 3 is not yet released, but this is on track to become it. This is based on commit: a815e11f7ebf35b59278f783227a829ee4692760. @feature.
2015-05-07 02:53:11 -07:00
static_libs/libunibreak/unibreakbase.h \
static_libs/libunibreak/unibreakdef.h \
Revert "Static deps: Move unibreak to be an external dep." Apparently the Debian package, while up to date, for some reason does not ship the .pc file (according to q66). According to Stefan, Fedora doesn't even have libunibreak, but only the previous naming and old version. Will have to wait a few years more. :( This reverts commit a2a9f33802a3923c1469789f66d5fdab1eaea943.
2015-05-07 02:40:57 -07:00
static_libs/libunibreak/linebreak.h \
static_libs/libunibreak/linebreakdef.h \
static_libs/libunibreak/wordbreakdef.h \
static_libs/libunibreak/wordbreak.h \
static_libs/libunibreak/wordbreakdata.c
# Linebreak
Static deps: Move unibreak to be an external dep. We need any version of libunibreak. The first one has been released in mid 2012. Even slow distros like ubuntu already have an LTS out with a good enough version, so I consider this enough to remove the maintenance cost. This has been discussed on IRC. @feature
2015-05-07 02:02:40 -07:00
lib_evas_libevas_la_SOURCES = \
Static deps unibreak: update to what will soon be version 3. Version 3 is not yet released, but this is on track to become it. This is based on commit: a815e11f7ebf35b59278f783227a829ee4692760. @feature.
2015-05-07 02:53:11 -07:00
static_libs/libunibreak/unibreakbase.c \
static_libs/libunibreak/unibreakdef.c \
Revert "Static deps: Move unibreak to be an external dep." Apparently the Debian package, while up to date, for some reason does not ship the .pc file (according to q66). According to Stefan, Fedora doesn't even have libunibreak, but only the previous naming and old version. Will have to wait a few years more. :( This reverts commit a2a9f33802a3923c1469789f66d5fdab1eaea943.
2015-05-07 02:40:57 -07:00
static_libs/libunibreak/linebreak.c \
static_libs/libunibreak/linebreakdata.c \
static_libs/libunibreak/linebreakdef.c \
static_libs/libunibreak/wordbreak.c
# Main
lib_evas_libevas_la_SOURCES += \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib/evas/main.c
# Canvas
lib_evas_libevas_la_SOURCES += \
lib/evas/canvas/evas_callbacks.c \
lib/evas/canvas/evas_clip.c \
lib/evas/canvas/evas_data.c \
lib/evas/canvas/evas_device.c \
lib/evas/canvas/evas_events.c \
Evas: Extend pointer events and add legacy conversion routines To be honest, this commit is a bit of a mess since it's a rebased version of some temporary work patches.
2016-05-10 05:26:07 -07:00
lib/evas/canvas/evas_events_legacy.c \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib/evas/canvas/evas_focus.c \
lib/evas/canvas/evas_key.c \
lib/evas/canvas/evas_key_grab.c \
lib/evas/canvas/evas_layer.c \
lib/evas/canvas/evas_main.c \
lib/evas/canvas/evas_name.c \
Evas.Image: Move all legacy EAPI out of evas_object_image.c Some of these functions are still be in use by the new EO objects, like data_set/get/copy_set.
2016-03-15 00:19:12 -07:00
lib/evas/canvas/evas_image_legacy.c \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib/evas/canvas/evas_object_image.c \
lib/evas/canvas/evas_object_main.c \
lib/evas/canvas/evas_object_inform.c \
lib/evas/canvas/evas_object_intercept.c \
lib/evas/canvas/evas_object_line.c \
lib/evas/canvas/evas_object_polygon.c \
lib/evas/canvas/evas_object_rectangle.c \
lib/evas/canvas/evas_object_smart.c \
lib/evas/canvas/evas_object_smart_clipped.c \
lib/evas/canvas/evas_object_box.c \
lib/evas/canvas/evas_object_table.c \
lib/evas/canvas/evas_object_text.c \
lib/evas/canvas/evas_object_textblock.c \
Evas textblock: add support for hyphenation wrap style We now support hyphenation in style. Use "wrap=hyphenation" to use this wrap option. It will hyphenate based on explicit SOFT HYPHEN (&shy;) placement in the text, and with the (optional) assistance of dictionaries compatible with Hunspell's "hyphen" library. This wrap mode favors breaking at hyphen positions in a word, over moving the whole word to the next line. It will put an additional "-" at the break position if it was hyphened. Enabling the hyphen dictionaries is done by adding these configure options: --enable-hyphen (requires Hunspell's "hyphen" library installed) --with-dictionaries-hyphen-dir=DIR (specifies the install location of the actual .dic dictionary files e.g. /usr/share/hyphen) Note that dictionary files are expected to be in the form of "en_US.dic" or anything that ends with it e.g. "hyph_en_US.dic" (this how they are named in Arch Linux). @feature
2015-10-13 00:59:19 -07:00
lib/evas/canvas/evas_textblock_hyphenation.x \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib/evas/canvas/evas_object_textgrid.c \
lib/evas/canvas/evas_object_grid.c \
lib/evas/canvas/evas_font_dir.c \
lib/evas/canvas/evas_rectangle.c \
lib/evas/canvas/evas_render.c \
evas render2 - restructure it to be an explicit api call - cleaner to do
2015-03-19 22:18:17 -07:00
lib/evas/canvas/render2/evas_render2.c \
lib/evas/canvas/render2/evas_render2.h \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib/evas/canvas/evas_smart.c \
lib/evas/canvas/evas_async_events.c \
lib/evas/canvas/evas_stats.c \
lib/evas/canvas/evas_touch_point.c \
lib/evas/canvas/evas_map.c \
evas map: Move Efl.Gfx.Map mixin to its own C file
2017-04-25 22:04:21 -07:00
lib/evas/canvas/evas_map.h \
Add multiple output api support to evas... just "eo infra stubs" right now.
2013-04-08 04:02:58 -07:00
lib/evas/canvas/evas_gl.c \
Evas.Image: Add new classes Snapshot and Proxy Efl.Canvas.Snapshot and Efl.Canvas.Proxy are specialized classes previously implemented as features of Evas.Image. Note: this half of the work, as I suffered from a bad merge and rebase with my work branch on top of master.
2016-03-14 03:10:54 -07:00
lib/evas/canvas/evas_out.c \
Evas.Image: Create Efl.Canvas.Image for file & data images This replaces standard Evas_Object_Image when it is used "normally", ie. it's an image from a file or from a pixel buffer. All other APIs (proxy, snapshot, 3d, gl, ...) are disabled on this object. Also, reduce number of failing calls when the object is not a legacy object, but a legacy function is called. This is because a lot of image APIs are called internally using the legacy APIs, often in order to reset the state of the image object (eg. set file to NULL, etc...)
2016-03-16 03:37:04 -07:00
lib/evas/canvas/efl_canvas_image.c \
evas: add new event_grabber smart-ish object adding an "event rect" is a common use case for rectangles, but I needed a smarter event rect so I sent one off to school and it came back like this. an event_grabber is a smart object which functions like a normal event rect which has color(0,0,0,0), but with an important difference: it can have smart members. event propagation works differently for an event_grabber: normal: event -> layer -> smart(obj1,obj2,obj3) ->(?) other objects in this case, obj1,obj2,obj3 are all "inside" the smart object and their stacking will always be considered as being inside the smart object. rendering is also tied to the smart object in this case, as is clipping. an event which reaches a smart object will be sent to the objects inside, and then may continue through the smart object if there are no objects which block repeating. event_grabber: event -> layer -> event_grabber -> obj1,obj2,obj3 -> STOP in this case, obj1,obj2,obj3 are unmodified after being added to the event_grabber and can be stacked, rendered, and clipped completely independently of the event_grabber. the event_grabber is considered an "event_parent" for this case. member objects are not "inside" the event_grabber, and they are unable to receive events on their own. instead, the event_grabber, which must be stacked above all its members, receives events and propagates them top->down through its member objects. if none of the member objects block the repeat of an event then the event will still be blocked from further propagation past the event_grabber. object lifetimes are independent of the event_grabber; deleting the event_grabber has no effect on its members. @feature
2017-06-09 17:16:08 -07:00
lib/evas/canvas/efl_canvas_object_event_grabber.c \
Evas.Image: Add new classes Snapshot and Proxy Efl.Canvas.Snapshot and Efl.Canvas.Proxy are specialized classes previously implemented as features of Evas.Image. Note: this half of the work, as I suffered from a bad merge and rebase with my work branch on top of master.
2016-03-14 03:10:54 -07:00
lib/evas/canvas/efl_canvas_proxy.c \
Evas: Move 3d to Efl.Canvas.Scene3d This still seems a bit redondant with the underlying Evas.Canvas3d.Scene class.
2016-03-07 21:11:07 -08:00
lib/evas/canvas/efl_canvas_snapshot.c \
lib/evas/canvas/efl_canvas_scene3d.c \
Evas.Image: Move native surfaces to Efl.Canvas.Surface X11, TBM and Wayland support are implemented for now.
2016-03-08 23:21:08 -08:00
lib/evas/canvas/efl_canvas_surface.c \
lib/evas/canvas/efl_canvas_surface_tbm.c \
lib/evas/canvas/efl_canvas_surface_x11.c \
lib/evas/canvas/efl_canvas_surface_wayland.c \
evas map: Move Efl.Gfx.Map mixin to its own C file
2017-04-25 22:04:21 -07:00
lib/evas/canvas/efl_gfx_map.c \
efl: Rename Efl.Event.XX to Efl.Input.XX This removes: Efl.Event interface And renames: Efl.Event.Input -> Efl.Input.Event Efl.Event -> Efl.Input.Event (merged) Efl.Event.Pointer -> Efl.Input.Pointer Efl.Event.Key -> Efl.Input.Key Efl.Event.Hold -> Efl.Input.Hold This also moves some interfaces from efl/ to evas/ where they belong better. This allows renaming Eo_Event to Efl_Event.
2016-08-25 03:20:10 -07:00
lib/evas/canvas/efl_input_event.c \
lib/evas/canvas/efl_input_key.c \
lib/evas/canvas/efl_input_pointer.c \
lib/evas/canvas/efl_input_hold.c \
Evas: Add Focus event type.
2016-11-17 11:29:58 -08:00
lib/evas/canvas/efl_input_focus.c \
efl_animation: Add efl_animation Efl.Animation is a class which contains basic properties of animation for Efl.Canvas.Object.
2017-08-24 04:45:52 -07:00
lib/evas/canvas/efl_animation.c \
efl_animation: Add alpha animation
2017-08-24 18:14:51 -07:00
lib/evas/canvas/efl_animation_alpha.c \
efl_animation: Add rotate animation
2017-08-24 19:10:58 -07:00
lib/evas/canvas/efl_animation_rotate.c \
efl_animation: Add scale animation
2017-08-24 19:34:28 -07:00
lib/evas/canvas/efl_animation_scale.c \
efl_animation: Add translate animation
2017-08-24 21:37:12 -07:00
lib/evas/canvas/efl_animation_translate.c \
efl_animation: Add group animation Efl.Animation.Group is an abstract class which provides methods for group animations such as parallel and sequential group animations.
2017-08-25 01:08:59 -07:00
lib/evas/canvas/efl_animation_group.c \
efl_animation: Add parallel group animation and object Efl.Animation.Group.Parallel is a class for animations started in parallel. Efl.Animation.Object.Group.Parallel is a class which provides methods for an object of Efl.Animation.Group.Parallel. The objects added into the parallel group animation object start in parallel.
2017-08-25 01:54:29 -07:00
lib/evas/canvas/efl_animation_group_parallel.c \
efl_animation: Add sequential group animation and object Efl.Animation.Group.Sequential is a class for animations started in sequence. Efl.Animation.Object.Group.Sequential is a class which provides methods for an object of Efl.Animation.Group.Sequential. The objects added into the sequential group animation object start in sequence.
2017-08-29 20:08:41 -07:00
lib/evas/canvas/efl_animation_group_sequential.c \
efl_playable: split Efl.Player interface to Efl.Playable interface Summary: Efl.Player interface simply provides play functions, but another interface which indicates Efl.Player will play is also needed. Test Plan: Run elementary_test->Efl.Animation tests Reviewers: woohyun, conr2d, Jaehyun_Cho, jpeg, cedric Differential Revision: https://phab.enlightenment.org/D5662
2018-01-16 03:31:15 -08:00
lib/evas/canvas/efl_animation_player.c \
evas/gesture: Added touch accumulator class implementation.
2017-09-19 00:55:45 -07:00
lib/evas/gesture/efl_gesture_touch.c \
evas/gesture: Added gesture and tap gesture implementation.
2017-09-24 23:25:42 -07:00
lib/evas/gesture/efl_gesture.c \
lib/evas/gesture/efl_gesture_tap.c \
evas/gesture: Added long_tap gesture to gesture framework
2017-09-20 18:23:18 -07:00
lib/evas/gesture/efl_gesture_long_tap.c \
evas/gesture: added recognizer and tap recognizer implementation
2017-09-19 01:05:48 -07:00
lib/evas/gesture/efl_gesture_recognizer.c \
lib/evas/gesture/efl_gesture_recognizer_tap.c \
evas/gesture: Added long_tap gesture to gesture framework
2017-09-20 18:23:18 -07:00
lib/evas/gesture/efl_gesture_recognizer_long_tap.c \
evas/gesture: Added gesture manager implementaion.
2017-09-19 01:11:31 -07:00
lib/evas/gesture/efl_gesture_manager.c \
Evas: Move 3d to Efl.Canvas.Scene3d This still seems a bit redondant with the underlying Evas.Canvas3d.Scene class.
2016-03-07 21:11:07 -08:00
$(NULL)
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
build: split EXTRA_DIST files in src/ off from DISTFILES and handle separately This is again to avoid the "Argument list too long" error we are hitting more and more now. Given we just merged elementary, emotion generic players, evas generic loaders and elm_code it is not surprising we are hitting it again. This time the number of files being hold in DISTFILES has just grown to big so a make dist was no longer possible. If one looks at what the DISTFILES variable from automake holds you can image it grows a lot with all the source files plus generated files we have in tree now. DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) To cut off a big chunk but still keep all the other automagic in place for SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle the files in a dist-hook now. Another thing to note here is that this also only happens as we have the one big Makefile with includes. If we go back to per directory Makefiles this problem should vanish as well. In any case we need a solution for 1.18 now and this is what I have to offer. If you have a cleaner solution in mind feel welcome to test it out and if everything we need keeps working (make, make examples, make check, make benchmark, make dist and make distcheck) go ahead.
2016-06-08 01:26:06 -07:00
EXTRA_DIST2 += \
evas - render2 - ensure region files are in dist
2015-07-25 06:34:17 -07:00
lib/evas/canvas/render2/evas_render2_th_main.c \
lib/evas/canvas/render2/region.c \
lib/evas/canvas/render2/region.h
evas/render2: Put evas_render2_th_main.c in EXTRA_DIST to ship it in the tarball We are not able to put it in SOURCES as it is not possible to compile this as standalone object out of the context it is included in.
2015-06-10 01:08:39 -07:00
evas/vg: Added vg tree caching support
2017-10-26 17:11:02 -07:00
# Vg
lib_evas_libevas_la_SOURCES += \
lib/evas/vg/evas_vg_cache.c
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
# Cache
lib_evas_libevas_la_SOURCES += \
lib/evas/cache/evas_cache_image.c \
lib/evas/cache/evas_cache_engine_image.c \
lib/evas/cache/evas_preload.c \
lib/evas/cache/evas_cache.h
# Cache2 - Cserve2
if EVAS_CSERVE2
lib_evas_libevas_la_SOURCES += \
lib/evas/cache2/evas_cache2.c \
lib/evas/cache2/evas_cache2.h
lib_evas_libevas_la_SOURCES += \
lib/evas/cserve2/evas_cs2.h \
lib/evas/cserve2/evas_cs2_private.h \
lib/evas/cserve2/evas_cs2_image_data.c \
lib/evas/cserve2/evas_cs2_client.c
lib_evas_libevas_la_SOURCES += \
lib/evas/cserve2/evas_cs2_utils.h \
lib/evas/cserve2/evas_cs2_utils.c
endif
# File
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
lib_evas_file_SOURCES = \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib/evas/file/evas_module.c \
lib/evas/file/evas_module.h \
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
lib/evas/file/evas_path.c \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib/evas/file/evas_path.h
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
lib_evas_libevas_la_SOURCES += \
$(lib_evas_file_SOURCES)
evas: add initial Evas_Object_VG. Evas_Object_VG is meant to become an object that can hold a SVG scenegraph inside of it.
2015-04-03 07:12:59 -07:00
# Evas_3D
Evas: 3D: Introducing 3D scene rendering features Enable 3D features using --enable-evas-3d=yes when configuring. APIs are exposed through Evas_3D.h. Currently, evas-3d is being supported only on gl_x11 engine. Conflicts: src/lib/evas/Evas_Eo.h
2013-12-26 23:56:30 -08:00
noinst_HEADERS += \
evas/evas3d: cleanup docs and removed unncessary files. Conflicts: src/lib/evas/Evas_Legacy.h
2014-04-16 00:31:14 -07:00
lib/evas/include/evas_3d_utils.h
Evas: 3D: Introducing 3D scene rendering features Enable 3D features using --enable-evas-3d=yes when configuring. APIs are exposed through Evas_3D.h. Currently, evas-3d is being supported only on gl_x11 engine. Conflicts: src/lib/evas/Evas_Eo.h
2013-12-26 23:56:30 -08:00
lib_evas_libevas_la_SOURCES += \
evas: change interface evas_3d to evas_canvas3d Summary: Regard to https://phab.enlightenment.org/T2479 it is need for right generation Eolian files Reviewers: cedric Subscribers: cedric, tasn Differential Revision: https://phab.enlightenment.org/D2711 Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
2015-06-17 07:31:14 -07:00
lib/evas/canvas/evas_canvas3d_object.c \
lib/evas/canvas/evas_canvas3d_scene.c \
lib/evas/canvas/evas_canvas3d_node.c \
lib/evas/canvas/evas_canvas3d_camera.c \
lib/evas/canvas/evas_canvas3d_light.c \
lib/evas/canvas/evas_canvas3d_mesh.c \
lib/evas/canvas/evas_canvas3d_texture.c \
lib/evas/canvas/evas_canvas3d_material.c \
lib/evas/canvas/evas_canvas3d_primitive.c \
lib/evas/canvas/evas_canvas3d_node_callback.h
evas: replace and rename savers/loaders.
2014-11-27 03:27:01 -08:00
# Model savers/loaders (will be replaced to modules in next commits)
lib_evas_libevas_la_SOURCES += \
evas: move model save/load from common to common3d. Summary: Move model save/load to common3d. Here also will be common algorithms and structures which will be used in all loaders and savers. See task https://phab.enlightenment.org/T2713. Reviewers: cedric, Hermet, raster, Oleksander Subscribers: cedric Differential Revision: https://phab.enlightenment.org/D3030 Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
2015-11-09 14:44:36 -08:00
lib/evas/common3d/save_load/evas_model_load.c \
lib/evas/common3d/save_load/evas_model_save.c \
[Evas] Refactor model's savers and loaders. Summary: Move common part to a separated document. Make code more readable using smaller functions. (from Task T2713) Everything is OK with make check. Reviewers: cedric, raster, Hermet, stefan_schmidt Reviewed By: stefan_schmidt Subscribers: jpeg, artem.popov Differential Revision: https://phab.enlightenment.org/D3430
2015-12-28 20:28:55 -08:00
lib/evas/common3d/save_load/evas_model_load_save_common.c \
lib/evas/common3d/save_load/evas_model_load_save_common.h \
evas: replace and rename savers/loaders.
2014-11-27 03:27:01 -08:00
modules/evas/model_loaders/eet/evas_model_load_eet.c \
modules/evas/model_loaders/md2/evas_model_load_md2.c \
modules/evas/model_loaders/obj/evas_model_load_obj.c \
modules/evas/model_loaders/ply/evas_model_load_ply.c \
modules/evas/model_savers/eet/evas_model_save_eet.c \
modules/evas/model_savers/obj/evas_model_save_obj.c \
modules/evas/model_savers/ply/evas_model_save_ply.c \
evas: change interface evas_3d to evas_canvas3d Summary: Regard to https://phab.enlightenment.org/T2479 it is need for right generation Eolian files Reviewers: cedric Subscribers: cedric, tasn Differential Revision: https://phab.enlightenment.org/D2711 Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
2015-06-17 07:31:14 -07:00
lib/evas/canvas/evas_canvas3d_eet.c
Evas: 3D: Introducing 3D scene rendering features Enable 3D features using --enable-evas-3d=yes when configuring. APIs are exposed through Evas_3D.h. Currently, evas-3d is being supported only on gl_x11 engine. Conflicts: src/lib/evas/Evas_Eo.h
2013-12-26 23:56:30 -08:00
evas: add API for creation Evas_3D node primitives. Summary: Now mechanism of creation of primitives is similar to model loading. Reviewers: Oleksander, Hermet, raster, cedric Reviewed By: cedric Subscribers: cedric Differential Revision: https://phab.enlightenment.org/D2516 Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
2015-05-26 09:49:15 -07:00
# 3d primitives
lib_evas_libevas_la_SOURCES += \
lib/evas/common3d/primitives/tabulated_primitives/square.c \
lib/evas/common3d/primitives/tabulated_primitives/cube.c \
lib/evas/common3d/primitives/solids_of_revolution/sphere.c \
lib/evas/common3d/primitives/solids_of_revolution/torus.c \
lib/evas/common3d/primitives/solids_of_revolution/cylinder.c \
lib/evas/common3d/primitives/solids_of_revolution/cone.c \
lib/evas/common3d/primitives/surfaces/surface.c \
lib/evas/common3d/primitives/surfaces/terrain.c \
lib/evas/common3d/primitives/primitive_common.c
evas: add initial Evas_Object_VG. Evas_Object_VG is meant to become an object that can hold a SVG scenegraph inside of it.
2015-04-03 07:12:59 -07:00
# Evas_VG
lib_evas_libevas_la_SOURCES += \
evas/vg: renamed the evas_vg class to efl_canvas_vg Reviewers: jpeg Subscribers: jenkins, cedric Differential Revision: https://phab.enlightenment.org/D5357
2017-10-23 23:19:52 -07:00
lib/evas/canvas/efl_canvas_vg.c \
evas: add initial Evas_Object_VG. Evas_Object_VG is meant to become an object that can hold a SVG scenegraph inside of it.
2015-04-03 07:12:59 -07:00
lib/evas/canvas/evas_vg_node.c \
lib/evas/canvas/evas_vg_container.c \
lib/evas/canvas/evas_vg_gradient.c \
lib/evas/canvas/evas_vg_gradient_linear.c \
evas: add utility function to build path.
2015-04-03 07:13:00 -07:00
lib/evas/canvas/evas_vg_gradient_radial.c \
evas: add Evas_VG_Image.
2015-04-03 07:13:07 -07:00
lib/evas/canvas/evas_vg_utils.c \
evas: actually compile Evas_VG_Shape.
2015-04-03 07:14:50 -07:00
lib/evas/canvas/evas_vg_shape.c
evas: add initial Evas_Object_VG. Evas_Object_VG is meant to become an object that can hold a SVG scenegraph inside of it.
2015-04-03 07:12:59 -07:00
Evas: Move alpha functions to static_libs/draw This is a pretty simple code refactor, moving pixel handling to the new draw lib.
2015-12-02 22:29:32 -08:00
# Static draw lib
lib_evas_libevas_la_SOURCES += \
Evas filters: Implement mix3 func for rgba masking This operation was faked by running a mul and a blend ops. Now they are combined into one. A GL shader should also be able to do this in a single pass.
2015-12-03 22:43:27 -08:00
static_libs/draw/draw_alpha_main.c \
draw: Import or implement some colorspace conversion routines Those and many more will be required for proper map/unmap support. There will be problems with planar formats: YUV, RGB565_A5P, ETC1_ALPHA The quick solution to this problem is to not support region conversions, only full-image (so we can assume the location of the various planes in memory).
2016-03-22 00:57:52 -07:00
static_libs/draw/draw_convert.c \
Evas: Add all 'draw' files to evas static lib This should fix the build on old Ubuntu. I didn't get this error myself, but apparently the following issue happened:   CCLD   lib/ecore_evas/libecore_evas.la lib/evas/.libs/libevas.so: undefined reference to `efl_draw_neon_init' lib/evas/.libs/libevas.so: undefined reference to `efl_draw_sse2_init' collect2: ld returned 1 exit status Thanks @mer.kim for the report
2015-12-08 17:20:01 -08:00
static_libs/draw/draw_main_neon.c \
evas: etc code is now always needed for the color conversion logic.
2016-04-18 14:41:47 -07:00
static_libs/draw/draw_main.c \
static_libs/rg_etc/rg_etc1.c \
static_libs/rg_etc/rg_etc2.c \
static_libs/rg_etc/rg_etc1.h \
static_libs/rg_etc/etc2_encoder.c
Evas: Move alpha functions to static_libs/draw This is a pretty simple code refactor, moving pixel handling to the new draw lib.
2015-12-02 22:29:32 -08:00
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
# Engine
lib_evas_libevas_la_SOURCES += \
lib/evas/common/evas_op_copy_main_.c \
lib/evas/common/evas_op_blend_main_.c \
lib/evas/common/evas_op_add_main_.c \
lib/evas/common/evas_op_sub_main_.c \
lib/evas/common/evas_op_mask_main_.c \
lib/evas/common/evas_op_mul_main_.c \
lib/evas/common/evas_blend_main.c \
lib/evas/common/evas_blit_main.c \
lib/evas/common/evas_convert_color.c \
lib/evas/common/evas_convert_colorspace.c \
lib/evas/common/evas_convert_gry_1.c \
lib/evas/common/evas_convert_gry_8.c \
lib/evas/common/evas_convert_main.c \
lib/evas/common/evas_convert_rgb_16.c \
lib/evas/common/evas_convert_rgb_24.c \
lib/evas/common/evas_convert_rgb_8.c \
lib/evas/common/evas_convert_grypal_6.c \
lib/evas/common/evas_convert_yuv.c \
lib/evas/common/evas_cpu.c \
lib/evas/common/evas_draw_main.c \
lib/evas/common/evas_font_draw.c \
lib/evas/common/evas_font_load.c \
lib/evas/common/evas_font_main.c \
lib/evas/common/evas_font_query.c \
evas - fonts - move to using 4bit and rel 4 bit compressed font glyphs this changes the internal encoding of font glyphs in evas to use 4bit uncompressed if small, or 4bit rle (run length encoded) if larger. this caves at least 50% of memory on fonts - and more if bigger. with large fonts (40-80pixel size) we can save in the region of 80% of memory used for glyphs. this also happesn to allow speedups in rendering too.
2014-01-12 12:13:00 -08:00
lib/evas/common/evas_font_compress.c \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib/evas/common/evas_image_load.c \
lib/evas/common/evas_image_save.c \
lib/evas/common/evas_image_main.c \
lib/evas/common/evas_image_data.c \
lib/evas/common/evas_image_scalecache.c \
lib/evas/common/evas_line_main.c \
lib/evas/common/evas_polygon_main.c \
lib/evas/common/evas_rectangle_main.c \
lib/evas/common/evas_scale_main.c \
lib/evas/common/evas_scale_sample.c \
lib/evas/common/evas_scale_smooth.c \
lib/evas/common/evas_scale_span.c \
evas: Add thread threaded render queue SVN revision: 81280
2012-12-18 08:21:03 -08:00
lib/evas/common/evas_thread_render.c \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib/evas/common/evas_tiler.c \
lib/evas/common/evas_pipe.c \
lib/evas/common/language/evas_bidi_utils.c \
lib/evas/common/language/evas_language_utils.c \
lib/evas/common/evas_text_utils.c \
lib/evas/common/evas_font_ot.c \
lib/evas/common/evas_map_image.c \
lib/evas/common/evas_map_image.h \
lib/evas/common/evas_blend.h \
lib/evas/common/evas_blend_private.h \
lib/evas/common/evas_convert_color.h \
lib/evas/common/evas_convert_colorspace.h \
lib/evas/common/evas_convert_gry_1.h \
lib/evas/common/evas_convert_gry_8.h \
lib/evas/common/evas_convert_grypal_6.h \
lib/evas/common/evas_convert_main.h \
lib/evas/common/evas_convert_rgb_16.h \
lib/evas/common/evas_convert_rgb_24.h \
lib/evas/common/evas_convert_rgb_32.h \
lib/evas/common/evas_convert_rgb_8.h \
lib/evas/common/evas_convert_yuv.h \
lib/evas/common/evas_draw.h \
lib/evas/common/evas_font.h \
lib/evas/common/evas_font_default_walk.x \
lib/evas/common/evas_font_private.h \
lib/evas/common/evas_image.h \
lib/evas/common/evas_image_private.h \
lib/evas/common/evas_line.h \
lib/evas/common/evas_polygon.h \
lib/evas/common/evas_rectangle.h \
lib/evas/common/evas_scale_main.h \
lib/evas/common/evas_scale_smooth.h \
lib/evas/common/evas_scale_span.h \
lib/evas/common/evas_pipe.h \
lib/evas/common/language/evas_bidi_utils.h \
lib/evas/common/language/evas_language_utils.h \
lib/evas/common/language/evas_script_table.h \
lib/evas/common/evas_text_utils.h \
Remove evas internal dependency from the evas_font module Summary: dev branch : devs/subhransu/font The Final goal is to move the evas_font module to ector so that both ector and evas can reuse the code. make the api simple so that sam eapi can be used by evas_textblock and ector text. This is the 1st stage to achive that gola, first remove the evas internal dependancy as much as possible before moving to ector library. Reviewers: jpeg, raster, herdsman, cedric, id213sin Subscribers: cedric, jpeg Differential Revision: https://phab.enlightenment.org/D5419
2017-11-06 18:22:09 -08:00
lib/evas/common/evas_font_ot.h \
evas/common: added a generic cache in evas common.
2017-11-08 17:34:01 -08:00
lib/evas/common/evas_font_draw.h \
lib/evas/common/evas_common_generic_cache.c
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
add a global Efl_Config.h for everyone. * ned to replicate changes in other .pc.in files * need to replicate changes in other E*.h installed header files
2013-04-24 07:43:33 -07:00
lib_evas_libevas_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
evas render2 - restructure it to be an explicit api call - cleaner to do
2015-03-19 22:18:17 -07:00
-I$(top_srcdir)/src/lib/evas/canvas \
-I$(top_srcdir)/src/lib/evas/canvas/render2 \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
-I$(top_srcdir)/src/lib/evas/common \
evas: add common part of savers and loaders. Summary: Common part will make savers and loaders shorter and easier for understanding and refactoring. https://phab.enlightenment.org/T2713 - due to this task. Should be merged after https://phab.enlightenment.org/D3030 Should be merged to start adding refactored savers and loaders. Reviewers: Hermet, raster, Oleksander, cedric Subscribers: cedric Differential Revision: https://phab.enlightenment.org/D3038 Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
2015-11-09 15:01:54 -08:00
-I$(top_srcdir)/src/lib/evas/common3d/save_load \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/cserve2 \
-I$(top_srcdir)/src/lib/evas/file \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
-I$(top_srcdir)/src/lib/evas/include \
Revert "Static deps: Move unibreak to be an external dep." Apparently the Debian package, while up to date, for some reason does not ship the .pc file (according to q66). According to Stefan, Fedora doesn't even have libunibreak, but only the previous naming and old version. Will have to wait a few years more. :( This reverts commit a2a9f33802a3923c1469789f66d5fdab1eaea943.
2015-05-07 02:40:57 -07:00
-I$(top_srcdir)/src/static_libs/libunibreak \
Ector: Move drawhelper to static_libs Rename a few things: - draw helper -> efl_draw - Ector_Rop -> Efl.Gfx.Render_Op - ECTOR_ bla bla -> DRAW_ bla bla (base pixel ops) - ector_memfill -> draw_memset32 (and invert arg order to match memset) The main rasterizer file is now draw.h in static_libs/draw This is a non functional change, simple code refactor.
2015-12-02 01:46:29 -08:00
-I$(top_srcdir)/src/static_libs/draw \
cmake: add EFL_SUPPORT_LIB() and simplify/speedup its usage. generate a static library for src/static_libs and use that as LIBRARIES for the actual library, for those such as rg_etc that are used multiple times will even speed up the final build by compiling only once. Although not used, they can be made into shared libraries that would go inside /usr/lib/efl/support/v-1.19/libname.so
2017-01-27 06:38:52 -08:00
-I$(top_builddir)/src/lib \
evas: fix make distcheck.
2015-04-03 07:33:53 -07:00
-I$(top_builddir)/src/lib/evas/canvas \
evas/gesture: Added Eo classes for evas gesture framework.
2017-09-18 23:03:42 -07:00
-I$(top_builddir)/src/lib/evas/gesture \
ector: add engine-specific evas image buffer wrapper Since Evas still relies entirely on Image_Entry and Evas_GL_Image, we will need an engine-specific wrapper object creating a Buffer around an existing cached image. Currently only SW support is implemented. GL will be more fun to do (with glReadPixels and whatnot).
2015-12-08 00:29:54 -08:00
-I$(top_builddir)/src/lib/evas/include \
evas: fix make distcheck.
2015-04-03 07:33:53 -07:00
-I$(top_builddir)/src/modules/evas/engines/software_generic \
-I$(top_builddir)/src/modules/evas/engines/gl_generic \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-DPACKAGE_BIN_DIR=\"$(bindir)\" \
-DPACKAGE_LIB_DIR=\"$(libdir)\" \
-DPACKAGE_DATA_DIR=\"$(datadir)/evas\" \
autotools: Fixed 'make examples' and 'make examples-install' It was broken in set-ups with ($(builddir) != $(srcdir)) && ($(builddir) != $(srcdir)/build)
2014-07-02 08:09:20 -07:00
-DPACKAGE_BUILD_DIR=\"$(abs_top_builddir)\" \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@EVAS_CFLAGS@ \
efl: fix valgrind build. weird enough to build with memcheck.h you just need valgrind's CFLAGS, not its libraries as they are not supposed to be used like that, throwing many bgPlain_ errors (vgPlain_tl_pre_clo_init, vgPlain_free...) from libcoregrind-x86-linux.a SVN revision: 81901
2012-12-30 05:30:13 -08:00
@VALGRIND_CFLAGS@ \
autotools: missing cflags for building NEON support.
2014-09-02 03:53:29 -07:00
@NEON_CFLAGS@ \
Evas filters: Mark API as @beta Until we're happy with it, keep the API as beta. The EDC support should not change, and the Lua either, but the API could potentially still change to accomodate for new needs (vector graphics, anyone?). If we're happy with the current interface, then we can remove the @beta flags.
2015-06-24 19:12:05 -07:00
@ALTIVEC_CFLAGS@ \
-DEFL_GFX_FILTER_BETA
efl/evas: Fix using sse3 for all files We need to pass -sse3 to compile only in the file that checks for SSE3. Otherwise even for plain C compiler is free to use sse3 instructions. But they won't work if the CPU doesn't support it and therefore will SIGILL. SVN revision: 78973
2012-11-07 09:37:35 -08:00
# SSE3
noinst_LTLIBRARIES += lib/evas/common/libevas_op_blend_sse3.la
lib_evas_common_libevas_op_blend_sse3_la_SOURCES = \
Evas: Fix build for ubuntu... again See 75fed54f0e4d72b20860 Apparently the proper CFLAGS are not set for SSE compilation. SSE flags are set only for a specific file (now 2 of them). As usual, it was worksforme but not for others. This should probably fix that. Thanks Sub for the report and testing this solution.
2015-12-08 23:58:48 -08:00
lib/evas/common/evas_op_blend/op_blend_master_sse3.c \
static_libs/draw/draw_main_sse2.c
efl/evas: Fix using sse3 for all files We need to pass -sse3 to compile only in the file that checks for SSE3. Otherwise even for plain C compiler is free to use sse3 instructions. But they won't work if the CPU doesn't support it and therefore will SIGILL. SVN revision: 78973
2012-11-07 09:37:35 -08:00
add a global Efl_Config.h for everyone. * ned to replicate changes in other .pc.in files * need to replicate changes in other E*.h installed header files
2013-04-24 07:43:33 -07:00
lib_evas_common_libevas_op_blend_sse3_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
efl/evas: Fix using sse3 for all files We need to pass -sse3 to compile only in the file that checks for SSE3. Otherwise even for plain C compiler is free to use sse3 instructions. But they won't work if the CPU doesn't support it and therefore will SIGILL. SVN revision: 78973
2012-11-07 09:37:35 -08:00
$(lib_evas_libevas_la_CPPFLAGS) \
efl: turn cpu extensions detection into generic section, simplify a bit. * remove EVAS_ prefix as it may be used by other libs some day. * SSE3 is detected at runtime if x86. * remove AC_SUBST([altivec_cflags]) as it was not being used anywhere. * moved to top of file (maybe position is not optimal, let's wait vtorri to review) * simplified single-line summary that is as informative as before. SVN revision: 80284
2012-12-05 15:18:59 -08:00
@SSE3_CFLAGS@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
lib_evas_common_libevas_op_blend_sse3_la_LIBADD = @EVAS_LIBS@
lib_evas_common_libevas_op_blend_sse3_la_DEPENDENCIES = @EVAS_INTERNAL_LIBS@
merge: do not use recursive make for unit tests SVN revision: 79413
2012-11-17 23:12:38 -08:00
@feature - Apply NEON intrisics improvement to rotation
2014-02-27 14:04:52 -08:00
# maybe neon, maybe not
noinst_LTLIBRARIES += lib/evas/common/libevas_convert_rgb_32.la
lib_evas_common_libevas_convert_rgb_32_la_SOURCES = \
lib/evas/common/evas_convert_rgb_32.c
lib_evas_common_libevas_convert_rgb_32_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
$(lib_evas_libevas_la_CPPFLAGS) \
@NEON_CFLAGS@
lib_evas_common_libevas_convert_rgb_32_la_LIBADD = @EVAS_LIBS@
lib_evas_common_libevas_convert_rgb_32_la_DEPENDENCIES = @EVAS_INTERNAL_LIBS@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib_evas_libevas_la_CXXFLAGS =
lib_evas_libevas_la_LIBADD = \
efl/evas: Fix using sse3 for all files We need to pass -sse3 to compile only in the file that checks for SSE3. Otherwise even for plain C compiler is free to use sse3 instructions. But they won't work if the CPU doesn't support it and therefore will SIGILL. SVN revision: 78973
2012-11-07 09:37:35 -08:00
lib/evas/common/libevas_op_blend_sse3.la \
@feature - Apply NEON intrisics improvement to rotation
2014-02-27 14:04:52 -08:00
lib/evas/common/libevas_convert_rgb_32.la \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@EVAS_LIBS@
lib_evas_libevas_la_DEPENDENCIES = \
lib/evas/common/libevas_op_blend_sse3.la \
@feature - Apply NEON intrisics improvement to rotation
2014-02-27 14:04:52 -08:00
lib/evas/common/libevas_convert_rgb_32.la \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@EVAS_INTERNAL_LIBS@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
efl: unify LDFLAGS for LTLIBRARIES SVN revision: 81911
2012-12-30 14:15:29 -08:00
lib_evas_libevas_la_LDFLAGS = @EFL_LTLIBRARY_FLAGS@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
Revert "Static deps: Move unibreak to be an external dep." Apparently the Debian package, while up to date, for some reason does not ship the .pc file (according to q66). According to Stefan, Fedora doesn't even have libunibreak, but only the previous naming and old version. Will have to wait a few years more. :( This reverts commit a2a9f33802a3923c1469789f66d5fdab1eaea943.
2015-05-07 02:40:57 -07:00
# Linebreak
build: split EXTRA_DIST files in src/ off from DISTFILES and handle separately This is again to avoid the "Argument list too long" error we are hitting more and more now. Given we just merged elementary, emotion generic players, evas generic loaders and elm_code it is not surprising we are hitting it again. This time the number of files being hold in DISTFILES has just grown to big so a make dist was no longer possible. If one looks at what the DISTFILES variable from automake holds you can image it grows a lot with all the source files plus generated files we have in tree now. DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) To cut off a big chunk but still keep all the other automagic in place for SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle the files in a dist-hook now. Another thing to note here is that this also only happens as we have the one big Makefile with includes. If we go back to per directory Makefiles this problem should vanish as well. In any case we need a solution for 1.18 now and this is what I have to offer. If you have a cleaner solution in mind feel welcome to test it out and if everything we need keeps working (make, make examples, make check, make benchmark, make dist and make distcheck) go ahead.
2016-06-08 01:26:06 -07:00
EXTRA_DIST2 += \
Revert "Static deps: Move unibreak to be an external dep." Apparently the Debian package, while up to date, for some reason does not ship the .pc file (according to q66). According to Stefan, Fedora doesn't even have libunibreak, but only the previous naming and old version. Will have to wait a few years more. :( This reverts commit a2a9f33802a3923c1469789f66d5fdab1eaea943.
2015-05-07 02:40:57 -07:00
static_libs/libunibreak/LICENCE \
static_libs/libunibreak/AUTHORS \
static_libs/libunibreak/NEWS \
libunibreak: Follow README rename in EXTRA_DIST for distcheck. The latest libunibreak updated changed the README name to README.md. Follow this for the EXTRA_DIST files.
2015-05-08 05:29:13 -07:00
static_libs/libunibreak/README.md \
Revert "Static deps: Move unibreak to be an external dep." Apparently the Debian package, while up to date, for some reason does not ship the .pc file (according to q66). According to Stefan, Fedora doesn't even have libunibreak, but only the previous naming and old version. Will have to wait a few years more. :( This reverts commit a2a9f33802a3923c1469789f66d5fdab1eaea943.
2015-05-07 02:40:57 -07:00
static_libs/libunibreak/ChangeLog
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
# Engines
build: split EXTRA_DIST files in src/ off from DISTFILES and handle separately This is again to avoid the "Argument list too long" error we are hitting more and more now. Given we just merged elementary, emotion generic players, evas generic loaders and elm_code it is not surprising we are hitting it again. This time the number of files being hold in DISTFILES has just grown to big so a make dist was no longer possible. If one looks at what the DISTFILES variable from automake holds you can image it grows a lot with all the source files plus generated files we have in tree now. DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) To cut off a big chunk but still keep all the other automagic in place for SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle the files in a dist-hook now. Another thing to note here is that this also only happens as we have the one big Makefile with includes. If we go back to per directory Makefiles this problem should vanish as well. In any case we need a solution for 1.18 now and this is what I have to offer. If you have a cleaner solution in mind feel welcome to test it out and if everything we need keeps working (make, make examples, make check, make benchmark, make dist and make distcheck) go ahead.
2016-06-08 01:26:06 -07:00
EXTRA_DIST2 += \
evas - fonts - move to using 4bit and rel 4 bit compressed font glyphs this changes the internal encoding of font glyphs in evas to use 4bit uncompressed if small, or 4bit rle (run length encoded) if larger. this caves at least 50% of memory on fonts - and more if bigger. with large fonts (40-80pixel size) we can save in the region of 80% of memory used for glyphs. this also happesn to allow speedups in rendering too.
2014-01-12 12:13:00 -08:00
lib/evas/common/evas_font_compress_draw.c \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib/evas/common/evas_map_image_internal.c \
lib/evas/common/evas_map_image_core.c \
lib/evas/common/evas_map_image_loop.c \
evas/map: support aa in basic c computation.
2014-11-25 22:12:25 -08:00
lib/evas/common/evas_map_image_aa.c \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib/evas/common/evas_scale_smooth_scaler.c \
lib/evas/common/evas_scale_smooth_scaler_down.c \
lib/evas/common/evas_scale_smooth_scaler_downx.c \
lib/evas/common/evas_scale_smooth_scaler_downx_downy.c \
lib/evas/common/evas_scale_smooth_scaler_downy.c \
lib/evas/common/evas_scale_smooth_scaler_noscale.c \
lib/evas/common/evas_scale_smooth_scaler_up.c
# evas_op_add
build: split EXTRA_DIST files in src/ off from DISTFILES and handle separately This is again to avoid the "Argument list too long" error we are hitting more and more now. Given we just merged elementary, emotion generic players, evas generic loaders and elm_code it is not surprising we are hitting it again. This time the number of files being hold in DISTFILES has just grown to big so a make dist was no longer possible. If one looks at what the DISTFILES variable from automake holds you can image it grows a lot with all the source files plus generated files we have in tree now. DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) To cut off a big chunk but still keep all the other automagic in place for SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle the files in a dist-hook now. Another thing to note here is that this also only happens as we have the one big Makefile with includes. If we go back to per directory Makefiles this problem should vanish as well. In any case we need a solution for 1.18 now and this is what I have to offer. If you have a cleaner solution in mind feel welcome to test it out and if everything we need keeps working (make, make examples, make check, make benchmark, make dist and make distcheck) go ahead.
2016-06-08 01:26:06 -07:00
EXTRA_DIST2 += \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib/evas/common/evas_op_add/op_add_color_.c \
lib/evas/common/evas_op_add/op_add_color_i386.c \
lib/evas/common/evas_op_add/op_add_mask_color_.c \
lib/evas/common/evas_op_add/op_add_mask_color_i386.c \
lib/evas/common/evas_op_add/op_add_pixel_.c \
lib/evas/common/evas_op_add/op_add_pixel_color_.c \
lib/evas/common/evas_op_add/op_add_pixel_color_i386.c \
lib/evas/common/evas_op_add/op_add_pixel_i386.c \
lib/evas/common/evas_op_add/op_add_pixel_mask_.c \
lib/evas/common/evas_op_add/op_add_pixel_mask_i386.c
# evas_op_blend
build: split EXTRA_DIST files in src/ off from DISTFILES and handle separately This is again to avoid the "Argument list too long" error we are hitting more and more now. Given we just merged elementary, emotion generic players, evas generic loaders and elm_code it is not surprising we are hitting it again. This time the number of files being hold in DISTFILES has just grown to big so a make dist was no longer possible. If one looks at what the DISTFILES variable from automake holds you can image it grows a lot with all the source files plus generated files we have in tree now. DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) To cut off a big chunk but still keep all the other automagic in place for SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle the files in a dist-hook now. Another thing to note here is that this also only happens as we have the one big Makefile with includes. If we go back to per directory Makefiles this problem should vanish as well. In any case we need a solution for 1.18 now and this is what I have to offer. If you have a cleaner solution in mind feel welcome to test it out and if everything we need keeps working (make, make examples, make check, make benchmark, make dist and make distcheck) go ahead.
2016-06-08 01:26:06 -07:00
EXTRA_DIST2 += \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib/evas/common/evas_op_blend/op_blend_color_.c \
lib/evas/common/evas_op_blend/op_blend_color_i386.c \
lib/evas/common/evas_op_blend/op_blend_color_neon.c \
lib/evas/common/evas_op_blend/op_blend_color_sse3.c \
lib/evas/common/evas_op_blend/op_blend_mask_color_.c \
lib/evas/common/evas_op_blend/op_blend_mask_color_i386.c \
lib/evas/common/evas_op_blend/op_blend_mask_color_neon.c \
lib/evas/common/evas_op_blend/op_blend_mask_color_sse3.c \
lib/evas/common/evas_op_blend/op_blend_pixel_.c \
lib/evas/common/evas_op_blend/op_blend_pixel_color_.c \
lib/evas/common/evas_op_blend/op_blend_pixel_color_i386.c \
lib/evas/common/evas_op_blend/op_blend_pixel_color_neon.c \
lib/evas/common/evas_op_blend/op_blend_pixel_color_sse3.c \
lib/evas/common/evas_op_blend/op_blend_pixel_i386.c \
lib/evas/common/evas_op_blend/op_blend_pixel_mask_.c \
lib/evas/common/evas_op_blend/op_blend_pixel_mask_i386.c \
lib/evas/common/evas_op_blend/op_blend_pixel_mask_neon.c \
lib/evas/common/evas_op_blend/op_blend_pixel_mask_sse3.c \
lib/evas/common/evas_op_blend/op_blend_pixel_neon.c \
lib/evas/common/evas_op_blend/op_blend_pixel_sse3.c
# evas_op_copy
build: split EXTRA_DIST files in src/ off from DISTFILES and handle separately This is again to avoid the "Argument list too long" error we are hitting more and more now. Given we just merged elementary, emotion generic players, evas generic loaders and elm_code it is not surprising we are hitting it again. This time the number of files being hold in DISTFILES has just grown to big so a make dist was no longer possible. If one looks at what the DISTFILES variable from automake holds you can image it grows a lot with all the source files plus generated files we have in tree now. DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) To cut off a big chunk but still keep all the other automagic in place for SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle the files in a dist-hook now. Another thing to note here is that this also only happens as we have the one big Makefile with includes. If we go back to per directory Makefiles this problem should vanish as well. In any case we need a solution for 1.18 now and this is what I have to offer. If you have a cleaner solution in mind feel welcome to test it out and if everything we need keeps working (make, make examples, make check, make benchmark, make dist and make distcheck) go ahead.
2016-06-08 01:26:06 -07:00
EXTRA_DIST2 += \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib/evas/common/evas_op_copy/op_copy_color_.c \
lib/evas/common/evas_op_copy/op_copy_color_i386.c \
lib/evas/common/evas_op_copy/op_copy_color_neon.c \
lib/evas/common/evas_op_copy/op_copy_mask_color_.c \
lib/evas/common/evas_op_copy/op_copy_mask_color_i386.c \
lib/evas/common/evas_op_copy/op_copy_mask_color_neon.c \
lib/evas/common/evas_op_copy/op_copy_pixel_.c \
lib/evas/common/evas_op_copy/op_copy_pixel_neon.c \
lib/evas/common/evas_op_copy/op_copy_pixel_color_.c \
lib/evas/common/evas_op_copy/op_copy_pixel_color_i386.c \
lib/evas/common/evas_op_copy/op_copy_pixel_color_neon.c \
lib/evas/common/evas_op_copy/op_copy_pixel_i386.c \
lib/evas/common/evas_op_copy/op_copy_pixel_mask_.c \
lib/evas/common/evas_op_copy/op_copy_pixel_mask_i386.c \
lib/evas/common/evas_op_copy/op_copy_pixel_mask_neon.c
# evas_op_mask
build: split EXTRA_DIST files in src/ off from DISTFILES and handle separately This is again to avoid the "Argument list too long" error we are hitting more and more now. Given we just merged elementary, emotion generic players, evas generic loaders and elm_code it is not surprising we are hitting it again. This time the number of files being hold in DISTFILES has just grown to big so a make dist was no longer possible. If one looks at what the DISTFILES variable from automake holds you can image it grows a lot with all the source files plus generated files we have in tree now. DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) To cut off a big chunk but still keep all the other automagic in place for SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle the files in a dist-hook now. Another thing to note here is that this also only happens as we have the one big Makefile with includes. If we go back to per directory Makefiles this problem should vanish as well. In any case we need a solution for 1.18 now and this is what I have to offer. If you have a cleaner solution in mind feel welcome to test it out and if everything we need keeps working (make, make examples, make check, make benchmark, make dist and make distcheck) go ahead.
2016-06-08 01:26:06 -07:00
EXTRA_DIST2 += \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib/evas/common/evas_op_mask/op_mask_color_.c \
lib/evas/common/evas_op_mask/op_mask_color_i386.c \
lib/evas/common/evas_op_mask/op_mask_mask_color_.c \
lib/evas/common/evas_op_mask/op_mask_mask_color_i386.c \
lib/evas/common/evas_op_mask/op_mask_pixel_.c \
lib/evas/common/evas_op_mask/op_mask_pixel_color_.c \
lib/evas/common/evas_op_mask/op_mask_pixel_color_i386.c \
lib/evas/common/evas_op_mask/op_mask_pixel_i386.c \
lib/evas/common/evas_op_mask/op_mask_pixel_mask_.c \
lib/evas/common/evas_op_mask/op_mask_pixel_mask_i386.c
# evas_op_mul
build: split EXTRA_DIST files in src/ off from DISTFILES and handle separately This is again to avoid the "Argument list too long" error we are hitting more and more now. Given we just merged elementary, emotion generic players, evas generic loaders and elm_code it is not surprising we are hitting it again. This time the number of files being hold in DISTFILES has just grown to big so a make dist was no longer possible. If one looks at what the DISTFILES variable from automake holds you can image it grows a lot with all the source files plus generated files we have in tree now. DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) To cut off a big chunk but still keep all the other automagic in place for SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle the files in a dist-hook now. Another thing to note here is that this also only happens as we have the one big Makefile with includes. If we go back to per directory Makefiles this problem should vanish as well. In any case we need a solution for 1.18 now and this is what I have to offer. If you have a cleaner solution in mind feel welcome to test it out and if everything we need keeps working (make, make examples, make check, make benchmark, make dist and make distcheck) go ahead.
2016-06-08 01:26:06 -07:00
EXTRA_DIST2 += \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib/evas/common/evas_op_mul/op_mul_color_.c \
lib/evas/common/evas_op_mul/op_mul_color_i386.c \
lib/evas/common/evas_op_mul/op_mul_mask_color_.c \
lib/evas/common/evas_op_mul/op_mul_mask_color_i386.c \
lib/evas/common/evas_op_mul/op_mul_pixel_.c \
lib/evas/common/evas_op_mul/op_mul_pixel_color_.c \
lib/evas/common/evas_op_mul/op_mul_pixel_color_i386.c \
lib/evas/common/evas_op_mul/op_mul_pixel_i386.c \
lib/evas/common/evas_op_mul/op_mul_pixel_mask_.c \
lib/evas/common/evas_op_mul/op_mul_pixel_mask_i386.c
# evas_op_sub
build: split EXTRA_DIST files in src/ off from DISTFILES and handle separately This is again to avoid the "Argument list too long" error we are hitting more and more now. Given we just merged elementary, emotion generic players, evas generic loaders and elm_code it is not surprising we are hitting it again. This time the number of files being hold in DISTFILES has just grown to big so a make dist was no longer possible. If one looks at what the DISTFILES variable from automake holds you can image it grows a lot with all the source files plus generated files we have in tree now. DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) To cut off a big chunk but still keep all the other automagic in place for SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle the files in a dist-hook now. Another thing to note here is that this also only happens as we have the one big Makefile with includes. If we go back to per directory Makefiles this problem should vanish as well. In any case we need a solution for 1.18 now and this is what I have to offer. If you have a cleaner solution in mind feel welcome to test it out and if everything we need keeps working (make, make examples, make check, make benchmark, make dist and make distcheck) go ahead.
2016-06-08 01:26:06 -07:00
EXTRA_DIST2 += \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib/evas/common/evas_op_sub/op_sub_color_.c \
lib/evas/common/evas_op_sub/op_sub_color_i386.c \
lib/evas/common/evas_op_sub/op_sub_mask_color_.c \
lib/evas/common/evas_op_sub/op_sub_mask_color_i386.c \
lib/evas/common/evas_op_sub/op_sub_pixel_.c \
lib/evas/common/evas_op_sub/op_sub_pixel_color_.c \
lib/evas/common/evas_op_sub/op_sub_pixel_color_i386.c \
lib/evas/common/evas_op_sub/op_sub_pixel_i386.c \
lib/evas/common/evas_op_sub/op_sub_pixel_mask_.c \
lib/evas/common/evas_op_sub/op_sub_pixel_mask_i386.c
Evas filters: Add all filters to Makefile Compile the following evas_filter files: - evas_filter.c - blend.c - blur.c - bump.c - curve.c - displace.c - mask.c - parser.c
2013-12-09 03:27:33 -08:00
### Evas filters
Evas filters: EO-ify the filters API This creates the new interface Efl.Gfx.Filter And the implementation is a mixin (evas_filter_mixin.c): Evas.Filter All the filter rendering code has now been moved to this new file. TODO: Merge image filtering.
2015-06-17 00:26:30 -07:00
lib_evas_libevas_la_SOURCES += \
lib/evas/canvas/evas_filter_mixin.c \
lib/evas/filters/evas_filter.c \
Evas filters: Move scaling to a common file NOTE: Alpha scaling is NOT supported. It could be faked in 3 expensive steps: 1. Draw to RGBA 2. Scale RGBA 3. Draw to Alpha.
2014-01-01 19:43:44 -08:00
lib/evas/filters/evas_filter_parser.c \
fix distckeck for filter
2014-02-07 18:36:06 -08:00
lib/evas/filters/evas_filter_utils.c \
lib/evas/filters/evas_filter_private.h
Evas filters: Add all filters to Makefile Compile the following evas_filter files: - evas_filter.c - blend.c - blur.c - bump.c - curve.c - displace.c - mask.c - parser.c
2013-12-09 03:27:33 -08:00
build: split EXTRA_DIST files in src/ off from DISTFILES and handle separately This is again to avoid the "Argument list too long" error we are hitting more and more now. Given we just merged elementary, emotion generic players, evas generic loaders and elm_code it is not surprising we are hitting it again. This time the number of files being hold in DISTFILES has just grown to big so a make dist was no longer possible. If one looks at what the DISTFILES variable from automake holds you can image it grows a lot with all the source files plus generated files we have in tree now. DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) To cut off a big chunk but still keep all the other automagic in place for SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle the files in a dist-hook now. Another thing to note here is that this also only happens as we have the one big Makefile with includes. If we go back to per directory Makefiles this problem should vanish as well. In any case we need a solution for 1.18 now and this is what I have to offer. If you have a cleaner solution in mind feel welcome to test it out and if everything we need keeps working (make, make examples, make check, make benchmark, make dist and make distcheck) go ahead.
2016-06-08 01:26:06 -07:00
EXTRA_DIST2 += \
evas filters: Move blur to software generic (8/8) This completes the series of refactoring patches, where only the filter implementation is moved to the engine rather than inside evas itself.
2017-01-17 04:18:46 -08:00
modules/evas/engines/software_generic/filters/blur/blur_gaussian_alpha_.c \
modules/evas/engines/software_generic/filters/blur/blur_gaussian_rgba_.c \
modules/evas/engines/software_generic/filters/blur/blur_box_alpha_.c \
modules/evas/engines/software_generic/filters/blur/blur_box_alpha_i386.c \
modules/evas/engines/software_generic/filters/blur/blur_box_alpha_sse3.c \
modules/evas/engines/software_generic/filters/blur/blur_box_alpha_neon.c \
modules/evas/engines/software_generic/filters/blur/blur_box_rgba_.c \
modules/evas/engines/software_generic/filters/blur/blur_box_rgba_i386.c \
modules/evas/engines/software_generic/filters/blur/blur_box_rgba_sse3.c \
modules/evas/engines/software_generic/filters/blur/blur_box_rgba_neon.c
Evas filters: Add template optimizable files for box blur The new files (i386, sse3 and neon) are basically empty and fallback to the C version. This is just to pave the way for full low-level optimization... if someone has the time and skills to do it :) Add both Alpha and RGBA template files.
2014-03-25 00:54:57 -07:00
evas filters: Move blend to software_generic (1/8) This is an attempt at refactoring the filters code so I can later implement GL support. This patch adds a few extra changes to remove avoid calling functions of libevas from the software engine: use the draw functions from static_libs/draw rather than evas_common APIs.
2017-01-16 23:13:35 -08:00
GFX_FILTER_SW_FILES = \
evas filters: Move fill to software generic (4/8) This also moves the header evas_engine_filter.h to its subdir.
2017-01-17 03:48:31 -08:00
modules/evas/engines/software_generic/filters/evas_engine_filter.h \
evas filters: Move blend to software_generic (1/8) This is an attempt at refactoring the filters code so I can later implement GL support. This patch adds a few extra changes to remove avoid calling functions of libevas from the software engine: use the draw functions from static_libs/draw rather than evas_common APIs.
2017-01-16 23:13:35 -08:00
modules/evas/engines/software_generic/filters/evas_filter_blend.c \
evas filters: Move blur to software generic (8/8) This completes the series of refactoring patches, where only the filter implementation is moved to the engine rather than inside evas itself.
2017-01-17 04:18:46 -08:00
modules/evas/engines/software_generic/filters/evas_filter_blur.c \
evas filters: Move bump to software generic (6/8)
2017-01-17 04:00:36 -08:00
modules/evas/engines/software_generic/filters/evas_filter_bump.c \
evas filters: Move curve to software generic (3/8) This moves the RGBA premul/unpremul functions to static_libs/draw.
2017-01-17 03:34:16 -08:00
modules/evas/engines/software_generic/filters/evas_filter_curve.c \
evas filters: Move displace to software generic (5/8)
2017-01-17 03:56:33 -08:00
modules/evas/engines/software_generic/filters/evas_filter_displace.c \
evas filters: Move fill to software generic (4/8) This also moves the header evas_engine_filter.h to its subdir.
2017-01-17 03:48:31 -08:00
modules/evas/engines/software_generic/filters/evas_filter_fill.c \
evas filters: Move mask to software generic (2/8)
2017-01-17 02:33:50 -08:00
modules/evas/engines/software_generic/filters/evas_filter_mask.c \
evas filters: Move transform to software generic (7/8)
2017-01-17 04:09:18 -08:00
modules/evas/engines/software_generic/filters/evas_filter_transform.c \
evas filters: Move blend to software_generic (1/8) This is an attempt at refactoring the filters code so I can later implement GL support. This patch adds a few extra changes to remove avoid calling functions of libevas from the software engine: use the draw functions from static_libs/draw rather than evas_common APIs.
2017-01-16 23:13:35 -08:00
$(NULL)
ector: add engine-specific evas image buffer wrapper Since Evas still relies entirely on Image_Entry and Evas_GL_Image, we will need an engine-specific wrapper object creating a Buffer around an existing cached image. Currently only SW support is implemented. GL will be more fun to do (with glReadPixels and whatnot).
2015-12-08 00:29:54 -08:00
### Engine Ector stuff
Evas: (try to) fix compilation Not even sure if it's parallel compilation or not... classic case of works-for-me. Hopefully this should fix the build for others.
2016-01-05 01:59:22 -08:00
evas_software_generic_eolian_files = \
ector: add engine-specific evas image buffer wrapper Since Evas still relies entirely on Image_Entry and Evas_GL_Image, we will need an engine-specific wrapper object creating a Buffer around an existing cached image. Currently only SW support is implemented. GL will be more fun to do (with glReadPixels and whatnot).
2015-12-08 00:29:54 -08:00
modules/evas/engines/software_generic/evas_ector_software_buffer.eo
build: split EXTRA_DIST files in src/ off from DISTFILES and handle separately This is again to avoid the "Argument list too long" error we are hitting more and more now. Given we just merged elementary, emotion generic players, evas generic loaders and elm_code it is not surprising we are hitting it again. This time the number of files being hold in DISTFILES has just grown to big so a make dist was no longer possible. If one looks at what the DISTFILES variable from automake holds you can image it grows a lot with all the source files plus generated files we have in tree now. DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) To cut off a big chunk but still keep all the other automagic in place for SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle the files in a dist-hook now. Another thing to note here is that this also only happens as we have the one big Makefile with includes. If we go back to per directory Makefiles this problem should vanish as well. In any case we need a solution for 1.18 now and this is what I have to offer. If you have a cleaner solution in mind feel welcome to test it out and if everything we need keeps working (make, make examples, make check, make benchmark, make dist and make distcheck) go ahead.
2016-06-08 01:26:06 -07:00
EXTRA_DIST2 += $(evas_software_generic_eolian_files)
Evas: (try to) fix compilation Not even sure if it's parallel compilation or not... classic case of works-for-me. Hopefully this should fix the build for others.
2016-01-05 01:59:22 -08:00
evas_software_generic_eolian_c = $(evas_software_generic_eolian_files:%.eo=%.eo.c)
evas_software_generic_eolian_h = $(evas_software_generic_eolian_files:%.eo=%.eo.h)
BUILT_SOURCES += \
$(evas_software_generic_eolian_c) \
$(evas_software_generic_eolian_h)
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
### Engines
if EVAS_STATIC_BUILD_SOFTWARE_GENERIC
ector: add engine-specific evas image buffer wrapper Since Evas still relies entirely on Image_Entry and Evas_GL_Image, we will need an engine-specific wrapper object creating a Buffer around an existing cached image. Currently only SW support is implemented. GL will be more fun to do (with glReadPixels and whatnot).
2015-12-08 00:29:54 -08:00
lib_evas_libevas_la_SOURCES += \
Evas_Engine: add TBM surface and clean up Native Struct Summary: Add TBM surface in wayland and clean up Native struct on Evas Engine. Previous TBM surface for evas_object_image's native_surface_set is only in Evas X11 backend. This patch has the code for wayland backend. In addition, evas_native_tbm.c is moved to software_generic. Becuase this file is common. And, Native in Evas_Engine is clean-up. @feature Test Plan: TBM surface is tested with spacegrapher's test app(tbm.c) in Tizen Device. Pixmap surface is tested in ubuntu with same test app. EvasGL is tested with elementary_test. Reviewers: jpeg, spacegrapher, raster, cedric Subscribers: dkdk, scholb.kim, JoogabYun Differential Revision: https://phab.enlightenment.org/D3501
2016-01-04 23:41:14 -08:00
modules/evas/engines/software_generic/evas_engine.c \
modules/evas/engines/software_generic/Evas_Engine_Software_Generic.h \
evas: Fix compilation after @cedric's "fix" Don't forget git add!
2016-12-08 17:48:35 -08:00
modules/evas/engines/software_generic/Evas_Engine_Software_Shared.h \
Evas_Engine: add TBM surface and clean up Native Struct Summary: Add TBM surface in wayland and clean up Native struct on Evas Engine. Previous TBM surface for evas_object_image's native_surface_set is only in Evas X11 backend. This patch has the code for wayland backend. In addition, evas_native_tbm.c is moved to software_generic. Becuase this file is common. And, Native in Evas_Engine is clean-up. @feature Test Plan: TBM surface is tested with spacegrapher's test app(tbm.c) in Tizen Device. Pixmap surface is tested in ubuntu with same test app. EvasGL is tested with elementary_test. Reviewers: jpeg, spacegrapher, raster, cedric Subscribers: dkdk, scholb.kim, JoogabYun Differential Revision: https://phab.enlightenment.org/D3501
2016-01-04 23:41:14 -08:00
modules/evas/engines/software_generic/evas_native_tbm.c \
software_generic: Add wayland dmabuf native surface support
2016-05-18 08:27:32 -07:00
modules/evas/engines/software_generic/evas_native_dmabuf.c \
Evas_Engine: add TBM surface and clean up Native Struct Summary: Add TBM surface in wayland and clean up Native struct on Evas Engine. Previous TBM surface for evas_object_image's native_surface_set is only in Evas X11 backend. This patch has the code for wayland backend. In addition, evas_native_tbm.c is moved to software_generic. Becuase this file is common. And, Native in Evas_Engine is clean-up. @feature Test Plan: TBM surface is tested with spacegrapher's test app(tbm.c) in Tizen Device. Pixmap surface is tested in ubuntu with same test app. EvasGL is tested with elementary_test. Reviewers: jpeg, spacegrapher, raster, cedric Subscribers: dkdk, scholb.kim, JoogabYun Differential Revision: https://phab.enlightenment.org/D3501
2016-01-04 23:41:14 -08:00
modules/evas/engines/software_generic/evas_ector_software_buffer.c \
evas filters: Move blend to software_generic (1/8) This is an attempt at refactoring the filters code so I can later implement GL support. This patch adds a few extra changes to remove avoid calling functions of libevas from the software engine: use the draw functions from static_libs/draw rather than evas_common APIs.
2017-01-16 23:13:35 -08:00
modules/evas/engines/software_generic/evas_native_common.h \
evas: Fix crash with filters Since the EO APIs are defined as weak symbols, invalid definitions of EAPI lead to runtime crashes on non-public APIs. This is a fix following a series of changes wrt. EAPI definitions.
2017-08-15 22:06:51 -07:00
modules/evas/engines/software_generic/evas_ector_software.h \
evas filters: Move blend to software_generic (1/8) This is an attempt at refactoring the filters code so I can later implement GL support. This patch adds a few extra changes to remove avoid calling functions of libevas from the software engine: use the draw functions from static_libs/draw rather than evas_common APIs.
2017-01-16 23:13:35 -08:00
$(GFX_FILTER_SW_FILES)
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib_evas_libevas_la_LIBADD +=
evas filters: Move blend to software_generic (1/8) This is an attempt at refactoring the filters code so I can later implement GL support. This patch adds a few extra changes to remove avoid calling functions of libevas from the software engine: use the draw functions from static_libs/draw rather than evas_common APIs.
2017-01-16 23:13:35 -08:00
lib_evas_libevas_la_CPPFLAGS += -I$(top_srcdir)/src/lib/ector \
-I$(top_srcdir)/src/lib/evas/filters
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
else
enginesoftwaregenericpkgdir = $(libdir)/evas/modules/engines/software_generic/$(MODULE_ARCH)
enginesoftwaregenericpkg_LTLIBRARIES = modules/evas/engines/software_generic/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_enginesoftwaregenericpkgLTLIBRARIES = install-enginesoftwaregenericpkgLTLIBRARIES
$(install_enginesoftwaregenericpkgLTLIBRARIES): install-libLTLIBRARIES
Evas_Engine: add TBM surface and clean up Native Struct Summary: Add TBM surface in wayland and clean up Native struct on Evas Engine. Previous TBM surface for evas_object_image's native_surface_set is only in Evas X11 backend. This patch has the code for wayland backend. In addition, evas_native_tbm.c is moved to software_generic. Becuase this file is common. And, Native in Evas_Engine is clean-up. @feature Test Plan: TBM surface is tested with spacegrapher's test app(tbm.c) in Tizen Device. Pixmap surface is tested in ubuntu with same test app. EvasGL is tested with elementary_test. Reviewers: jpeg, spacegrapher, raster, cedric Subscribers: dkdk, scholb.kim, JoogabYun Differential Revision: https://phab.enlightenment.org/D3501
2016-01-04 23:41:14 -08:00
modules_evas_engines_software_generic_module_la_SOURCES = \
modules/evas/engines/software_generic/evas_engine.c \
modules/evas/engines/software_generic/Evas_Engine_Software_Generic.h \
evas: Fix compilation after @cedric's "fix" Don't forget git add!
2016-12-08 17:48:35 -08:00
modules/evas/engines/software_generic/Evas_Engine_Software_Shared.h \
Evas_Engine: add TBM surface and clean up Native Struct Summary: Add TBM surface in wayland and clean up Native struct on Evas Engine. Previous TBM surface for evas_object_image's native_surface_set is only in Evas X11 backend. This patch has the code for wayland backend. In addition, evas_native_tbm.c is moved to software_generic. Becuase this file is common. And, Native in Evas_Engine is clean-up. @feature Test Plan: TBM surface is tested with spacegrapher's test app(tbm.c) in Tizen Device. Pixmap surface is tested in ubuntu with same test app. EvasGL is tested with elementary_test. Reviewers: jpeg, spacegrapher, raster, cedric Subscribers: dkdk, scholb.kim, JoogabYun Differential Revision: https://phab.enlightenment.org/D3501
2016-01-04 23:41:14 -08:00
modules/evas/engines/software_generic/evas_native_tbm.c \
software_generic: Add wayland dmabuf native surface support
2016-05-18 08:27:32 -07:00
modules/evas/engines/software_generic/evas_native_dmabuf.c \
Evas_Engine: add TBM surface and clean up Native Struct Summary: Add TBM surface in wayland and clean up Native struct on Evas Engine. Previous TBM surface for evas_object_image's native_surface_set is only in Evas X11 backend. This patch has the code for wayland backend. In addition, evas_native_tbm.c is moved to software_generic. Becuase this file is common. And, Native in Evas_Engine is clean-up. @feature Test Plan: TBM surface is tested with spacegrapher's test app(tbm.c) in Tizen Device. Pixmap surface is tested in ubuntu with same test app. EvasGL is tested with elementary_test. Reviewers: jpeg, spacegrapher, raster, cedric Subscribers: dkdk, scholb.kim, JoogabYun Differential Revision: https://phab.enlightenment.org/D3501
2016-01-04 23:41:14 -08:00
modules/evas/engines/software_generic/evas_ector_software_buffer.c \
evas filters: Move blend to software_generic (1/8) This is an attempt at refactoring the filters code so I can later implement GL support. This patch adds a few extra changes to remove avoid calling functions of libevas from the software engine: use the draw functions from static_libs/draw rather than evas_common APIs.
2017-01-16 23:13:35 -08:00
modules/evas/engines/software_generic/evas_native_common.h \
$(GFX_FILTER_SW_FILES)
add a global Efl_Config.h for everyone. * ned to replicate changes in other .pc.in files * need to replicate changes in other E*.h installed header files
2013-04-24 07:43:33 -07:00
modules_evas_engines_software_generic_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
-I$(top_srcdir)/src/lib/evas/cserve2 \
evas filters: Move blend to software_generic (1/8) This is an attempt at refactoring the filters code so I can later implement GL support. This patch adds a few extra changes to remove avoid calling functions of libevas from the software engine: use the draw functions from static_libs/draw rather than evas_common APIs.
2017-01-16 23:13:35 -08:00
-I$(top_srcdir)/src/lib/evas/filters \
evas: Rename software filter function type From Evas_Filter_Apply_Func to Software_Filter_Func. Also fix include dir for out-of-tree builds of non-static sw generic.
2017-01-17 05:15:09 -08:00
-I$(top_builddir)/src/lib/evas/canvas \
evas: fix make distcheck.
2015-04-03 07:33:53 -07:00
-I$(top_builddir)/src/modules/evas/engines/software_generic \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@EVAS_CFLAGS@
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
modules_evas_engines_software_generic_module_la_LIBADD = @USE_EVAS_LIBS@
modules_evas_engines_software_generic_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
efl: unbreak last commit. seems that automake will parse LDFLAGS for -module and if it's not present it will complain about name not starting with 'lib'. seems my last try was without NOCONFIGURE=1 and autogen continued to the old ./configure, that printed lots of messages and the error went unnoticed SVN revision: 81917
2012-12-30 17:13:47 -08:00
modules_evas_engines_software_generic_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_software_generic_module_la_LIBTOOLFLAGS = --tag=disable-static
endif
if BUILD_ENGINE_BUFFER
Revert "Evas: Stop installing Evas_Engine_Stuff.h" This reverts commit df3958bb892b313ab91b9f0bd5a84452bb62388c. 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.
2014-12-11 08:10:56 -08:00
dist_installed_evasmainheaders_DATA += modules/evas/engines/buffer/Evas_Engine_Buffer.h
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
BUFFER_SOURCES = \
modules/evas/engines/buffer/evas_engine.c \
modules/evas/engines/buffer/evas_outbuf.c \
modules/evas/engines/buffer/evas_engine.h
if EVAS_STATIC_BUILD_BUFFER
lib_evas_libevas_la_SOURCES += $(BUFFER_SOURCES)
else
enginebufferpkgdir = $(libdir)/evas/modules/engines/buffer/$(MODULE_ARCH)
enginebufferpkg_LTLIBRARIES = modules/evas/engines/buffer/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_enginebufferpkgLTLIBRARIES = install-enginebufferpkgLTLIBRARIES
$(install_enginebufferpkgLTLIBRARIES): install-libLTLIBRARIES
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_buffer_module_la_SOURCES = $(BUFFER_SOURCES)
add a global Efl_Config.h for everyone. * ned to replicate changes in other .pc.in files * need to replicate changes in other E*.h installed header files
2013-04-24 07:43:33 -07:00
modules_evas_engines_buffer_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
-I$(top_srcdir)/src/lib/evas/cserve2 \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@EVAS_CFLAGS@
modules_evas_engines_buffer_module_la_LIBADD = @USE_EVAS_LIBS@
modules_evas_engines_buffer_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
efl: unbreak last commit. seems that automake will parse LDFLAGS for -module and if it's not present it will complain about name not starting with 'lib'. seems my last try was without NOCONFIGURE=1 and autogen continued to the old ./configure, that printed lots of messages and the error went unnoticed SVN revision: 81917
2012-12-30 17:13:47 -08:00
modules_evas_engines_buffer_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_buffer_module_la_LIBTOOLFLAGS = --tag=disable-static
endif
endif
if BUILD_ENGINE_FB
FB_SOURCES = \
modules/evas/engines/fb/evas_engine.c \
modules/evas/engines/fb/evas_fb_main.c \
modules/evas/engines/fb/evas_outbuf.c \
modules/evas/engines/fb/evas_engine.h \
evas: remove all Engine Info headers installation except for the buffer engine. We do not have any upstream application using those headers and if any do, they should have proper auto detection of them being available or not. Today, most application should use Ecore_Evas directly. If the need reappear, we will reintroduce those headers one by one.
2016-12-05 11:35:19 -08:00
modules/evas/engines/fb/evas_fb.h \
modules/evas/engines/fb/Evas_Engine_FB.h
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
if EVAS_STATIC_BUILD_FB
lib_evas_libevas_la_SOURCES += $(FB_SOURCES)
lib_evas_libevas_la_CPPFLAGS += @evas_engine_fb_cflags@
lib_evas_libevas_la_LIBADD += @evas_engine_fb_libs@
else
enginefbpkgdir = $(libdir)/evas/modules/engines/fb/$(MODULE_ARCH)
enginefbpkg_LTLIBRARIES = modules/evas/engines/fb/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_enginefbpkgLTLIBRARIES = install-enginefbpkgLTLIBRARIES
$(install_enginefbpkgLTLIBRARIES): install-libLTLIBRARIES
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_fb_module_la_SOURCES = $(FB_SOURCES)
add a global Efl_Config.h for everyone. * ned to replicate changes in other .pc.in files * need to replicate changes in other E*.h installed header files
2013-04-24 07:43:33 -07:00
modules_evas_engines_fb_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
-I$(top_srcdir)/src/lib/evas/cserve2 \
@evas_engine_fb_cflags@ \
@EVAS_CFLAGS@
modules_evas_engines_fb_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@evas_engine_fb_libs@
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
modules_evas_engines_fb_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
efl: unbreak last commit. seems that automake will parse LDFLAGS for -module and if it's not present it will complain about name not starting with 'lib'. seems my last try was without NOCONFIGURE=1 and autogen continued to the old ./configure, that printed lots of messages and the error went unnoticed SVN revision: 81917
2012-12-30 17:13:47 -08:00
modules_evas_engines_fb_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_fb_module_la_LIBTOOLFLAGS = --tag=disable-static
endif
endif
GL_COMMON_SOURCES = \
modules/evas/engines/gl_common/evas_gl_private.h \
modules/evas/engines/gl_common/evas_gl_common.h \
evas: include new header file in build to fix distcheck Introduced in 72b13c3ebb0b5f117f3602871ec2842d4baac786 the new header was not deployed and thus not available in the tarball.
2015-10-01 03:19:52 -07:00
modules/evas/engines/gl_common/evas_gl_define.h \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules/evas/engines/gl_common/evas_gl_context.c \
Pulled out evas gl backend binary shader file caching code from evas_gl_shader.c file and made an internal generic caching api in evas_gl_common.h for use in other places ie. evas_gl. Then implemented evas_gl surface cap. caching code in gl backend to accelerate the engine creation. SVN revision: 82321
2013-01-06 22:16:18 -08:00
modules/evas/engines/gl_common/evas_gl_file_cache.c \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules/evas/engines/gl_common/evas_gl_shader.c \
modules/evas/engines/gl_common/evas_gl_rectangle.c \
modules/evas/engines/gl_common/evas_gl_texture.c \
evas: add support for asynchronously uploading GL texture. NOTE: when using Evas_Object image preload infrastructure the GL texture upload was uploaded from the main loop during the rendering stage. This could lead to some frame drop during fast animation due to the time needed to upload that texture. This patch fix this problem by uploading a small texture quickly (16x16) and waiting for going back to the main loop to be able to use the same GL context from another thread to do the texture upload asynchronously without blocking the main loop.
2013-06-23 19:41:32 -07:00
modules/evas/engines/gl_common/evas_gl_preload.c \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules/evas/engines/gl_common/evas_gl_image.c \
modules/evas/engines/gl_common/evas_gl_font.c \
modules/evas/engines/gl_common/evas_gl_polygon.c \
modules/evas/engines/gl_common/evas_gl_line.c \
modules/evas/engines/gl_common/evas_gl_core.c \
modules/evas/engines/gl_common/evas_gl_api_ext.h \
modules/evas/engines/gl_common/evas_gl_api_ext_def.h \
modules/evas/engines/gl_common/evas_gl_core.h \
modules/evas/engines/gl_common/evas_gl_core_private.h \
modules/evas/engines/gl_common/evas_gl_api.c \
evas/gl_common: add new header files to build to make them available for dist
2015-08-27 07:42:18 -07:00
modules/evas/engines/gl_common/evas_gl_api_def.h \
Evas GL: Add support for OpenGL-ES 1.1 (part 2) 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).
2014-09-22 03:15:37 -07:00
modules/evas/engines/gl_common/evas_gl_api_gles1.c \
evas/gl_common: add new header files to build to make them available for dist
2015-08-27 07:42:18 -07:00
modules/evas/engines/gl_common/evas_gl_api_gles3_def.h \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules/evas/engines/gl_common/evas_gl_api_ext.c \
Evas GL: Fix list of shaders to distribute 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.
2014-11-13 16:41:15 -08:00
modules/evas/engines/gl_common/shader/evas_gl_shaders.x \
Evas GL: Implement runtime generation and load of shaders Instead of generating the shaders at compile-time, do this at runtime. Also load only the required shaders in memory. This saves 25000 LOC, lots of strings inside the .so files and save a non negligible amount of memory since those shader binaries can weigh a few megabytes in total. The current shader selection mechanism is a bit complex and uses eina_hash_int32 but this can be optimized later if it's deemed too slow.
2015-11-04 22:39:32 -08:00
$(NULL)
Fix evas GL common engine to have a shader to do oversampling on downscaling. This makes quality much better and "at best" equates to a 16 point sample (2x2 linear interpolation samples, where a linear interpolation sample equates to a 2x2 sample). This will have perfomance impact, but the quality is worth it and makes it closer to software downscaling in quality. It supports 2x2, 2x1 and 1x2 oversampling. YUV not done, nor image mask (font shaders not needed).
2013-02-26 05:05:19 -08:00
Evas: 3D: Introducing 3D scene rendering features Enable 3D features using --enable-evas-3d=yes when configuring. APIs are exposed through Evas_3D.h. Currently, evas-3d is being supported only on gl_x11 engine. Conflicts: src/lib/evas/Evas_Eo.h
2013-12-26 23:56:30 -08:00
# 3D
GL_COMMON_SOURCES += \
modules/evas/engines/gl_common/evas_gl_3d_common.h \
modules/evas/engines/gl_common/evas_gl_3d_private.h \
modules/evas/engines/gl_common/evas_gl_3d.c \
modules/evas/engines/gl_common/evas_gl_3d_renderer.c \
evas: (Try to) fix shaders gen without breaking everything So... adding the .x files to BUILT_SOURCES means they would get deleted during clean. This was bad, but turned to be awful when this made the check for writability fail. See: 8a273158788d630e56b4dc14cdd44f0eaae6b7b5 2b8912462e0ec81efb8e30a63383b811f52e16f5 This commit reverts: 0b69356f1bbceab3261835bc2d4632f8f4669206 Notes: Please revert if this breaks the build for anyone. I'm pretty sure the use of top_srcdir is not recommended the way I've done it. I hate autofoo.
2016-06-23 22:36:10 -07:00
modules/evas/engines/gl_common/evas_gl_3d_shader.c \
modules/evas/engines/gl_common/shader_3d/evas_gl_3d_shaders.x \
$(NULL)
Evas: 3D: Introducing 3D scene rendering features Enable 3D features using --enable-evas-3d=yes when configuring. APIs are exposed through Evas_3D.h. Currently, evas-3d is being supported only on gl_x11 engine. Conflicts: src/lib/evas/Evas_Eo.h
2013-12-26 23:56:30 -08:00
build: fix duplicated use of the variable in multiple Makefile_*.am. GL_SHADERS_GEN is defined in the Makefile.am of Ector and Evas. As these Mafile_*.am are included in the same Makefile.am, there is a warning with multiple defined triggered by automake. So this patch rename these 2 variables Test Plan: autogen.sH Reviewers: jpeg, cedric Differential Revision: https://phab.enlightenment.org/D3711 Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
2016-02-18 13:25:21 -08:00
EVAS_GL_SHADERS_GEN = \
Evas GL common: Factorize shader generation code Remove all individual shaders, factorize everything into one vertex and one fragment shader. All previous functionality has been kept as is[*]. Some new features have been added (new shader types). This is a first step in simplifying and improving the shaders system. Next: simplify shader selection [*] Yeah, that's quite a bold statement here. Maybe I broke everything.
2015-03-31 23:15:51 -07:00
modules/evas/engines/gl_common/shader/gen_shaders.sh \
modules/evas/engines/gl_common/shader/fragment.glsl \
modules/evas/engines/gl_common/shader/vertex.glsl \
Evas GL: Implement runtime generation and load of shaders Instead of generating the shaders at compile-time, do this at runtime. Also load only the required shaders in memory. This saves 25000 LOC, lots of strings inside the .so files and save a non negligible amount of memory since those shader binaries can weigh a few megabytes in total. The current shader selection mechanism is a bit complex and uses eina_hash_int32 but this can be optimized later if it's deemed too slow.
2015-11-04 22:39:32 -08:00
modules/evas/engines/gl_common/shader/include.glsl \
Evas masking: Implement image masking for GL engines
2014-11-24 03:24:25 -08:00
$(NULL)
Fix evas GL common engine to have a shader to do oversampling on downscaling. This makes quality much better and "at best" equates to a 16 point sample (2x2 linear interpolation samples, where a linear interpolation sample equates to a 2x2 sample). This will have perfomance impact, but the quality is worth it and makes it closer to software downscaling in quality. It supports 2x2, 2x1 and 1x2 oversampling. YUV not done, nor image mask (font shaders not needed).
2013-02-26 05:05:19 -08:00
build: split EXTRA_DIST files in src/ off from DISTFILES and handle separately This is again to avoid the "Argument list too long" error we are hitting more and more now. Given we just merged elementary, emotion generic players, evas generic loaders and elm_code it is not surprising we are hitting it again. This time the number of files being hold in DISTFILES has just grown to big so a make dist was no longer possible. If one looks at what the DISTFILES variable from automake holds you can image it grows a lot with all the source files plus generated files we have in tree now. DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) To cut off a big chunk but still keep all the other automagic in place for SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle the files in a dist-hook now. Another thing to note here is that this also only happens as we have the one big Makefile with includes. If we go back to per directory Makefiles this problem should vanish as well. In any case we need a solution for 1.18 now and this is what I have to offer. If you have a cleaner solution in mind feel welcome to test it out and if everything we need keeps working (make, make examples, make check, make benchmark, make dist and make distcheck) go ahead.
2016-06-08 01:26:06 -07:00
EXTRA_DIST2 += $(EVAS_GL_SHADERS_GEN)
Evas shaders: Auto-generate the shaders from Makefile Let's regenerate the shaders when a SHD file changes. I've removed the Git commit id because only touching a file would insert a code change.
2014-11-11 21:55:34 -08:00
evas: (Try to) fix shaders gen without breaking everything So... adding the .x files to BUILT_SOURCES means they would get deleted during clean. This was bad, but turned to be awful when this made the check for writability fail. See: 8a273158788d630e56b4dc14cdd44f0eaae6b7b5 2b8912462e0ec81efb8e30a63383b811f52e16f5 This commit reverts: 0b69356f1bbceab3261835bc2d4632f8f4669206 Notes: Please revert if this breaks the build for anyone. I'm pretty sure the use of top_srcdir is not recommended the way I've done it. I hate autofoo.
2016-06-23 22:36:10 -07:00
modules/evas/engines/gl_common/shader/evas_gl_shaders.x: $(EVAS_GL_SHADERS_GEN) $(top_srcdir)/src/modules/evas/engines/gl_common/shader/gen_shaders.sh
evas: Make shaders regen an opt-in behaviour While the shaders automatic regeneration is very useful when working on shaders, it has been the source of too many build breaks. So I'm making this regeneration an opt-in. You work on shaders? Set the env var EFL_SHD_REGEN=1
2016-06-27 00:00:50 -07:00
@if [ "x$(EFL_SHD_REGEN)" = "x1" ] ; then \
echo " SHADERS $@" ; \
sh $(top_srcdir)/src/modules/evas/engines/gl_common/shader/gen_shaders.sh ; \
fi
evas: (Try to) fix shaders gen without breaking everything So... adding the .x files to BUILT_SOURCES means they would get deleted during clean. This was bad, but turned to be awful when this made the check for writability fail. See: 8a273158788d630e56b4dc14cdd44f0eaae6b7b5 2b8912462e0ec81efb8e30a63383b811f52e16f5 This commit reverts: 0b69356f1bbceab3261835bc2d4632f8f4669206 Notes: Please revert if this breaks the build for anyone. I'm pretty sure the use of top_srcdir is not recommended the way I've done it. I hate autofoo.
2016-06-23 22:36:10 -07:00
modules/evas/engines/gl_common/evas_gl_shader.c: modules/evas/engines/gl_common/shader/evas_gl_shaders.x
Evas GL: Fix list of shaders to distribute 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.
2014-11-13 16:41:15 -08:00
evas: Evas_3D - refactor shader system. Reviewers: Hermet, raster, jpeg, cedric Subscribers: artem.popov, cedric Differential Revision: https://phab.enlightenment.org/D1947 Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
2015-02-18 12:19:28 -08:00
# NOTE: order here should be equal with modes in file Evas_Eo.h
GL_SHADERS_3D_GEN = \
modules/evas/engines/gl_common/shader_3d/vertex_color_vert.shd \
modules/evas/engines/gl_common/shader_3d/vertex_color_frag.shd \
modules/evas/engines/gl_common/shader_3d/diffuse_vert.shd \
modules/evas/engines/gl_common/shader_3d/diffuse_frag.shd \
modules/evas/engines/gl_common/shader_3d/flat_vert.shd \
modules/evas/engines/gl_common/shader_3d/flat_frag.shd \
modules/evas/engines/gl_common/shader_3d/phong_vert.shd \
modules/evas/engines/gl_common/shader_3d/phong_frag.shd \
modules/evas/engines/gl_common/shader_3d/normal_map_vert.shd \
modules/evas/engines/gl_common/shader_3d/normal_map_frag.shd \
modules/evas/engines/gl_common/shader_3d/shadow_map_vert.shd \
modules/evas/engines/gl_common/shader_3d/shadow_map_frag.shd \
modules/evas/engines/gl_common/shader_3d/color_pick_vert.shd \
modules/evas/engines/gl_common/shader_3d/color_pick_frag.shd \
evas: Evas_3D - add parallax occlusion shading. Reviewers: Hermet, cedric Reviewed By: cedric Subscribers: cedric Differential Revision: https://phab.enlightenment.org/D2018
2015-02-23 05:25:49 -08:00
modules/evas/engines/gl_common/shader_3d/parallax_occlusion_vert.shd \
modules/evas/engines/gl_common/shader_3d/parallax_occlusion_frag.shd \
evas.canvas3d: Add FXAA post processing render. Summary: Add post processing render function as rendering full screen quard after rendering to texture. Add possibility use size of current frame in shader. Add FXAA shader source files Reviewers: raster, cedric, Hermet Subscribers: jpeg Differential Revision: https://phab.enlightenment.org/D3847
2016-04-11 08:50:46 -07:00
modules/evas/engines/gl_common/shader_3d/post_processing_fxaa_vert.shd \
modules/evas/engines/gl_common/shader_3d/post_processing_fxaa_frag.shd \
evas: Evas_3D - refactor shader system. Reviewers: Hermet, raster, jpeg, cedric Subscribers: artem.popov, cedric Differential Revision: https://phab.enlightenment.org/D1947 Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
2015-02-18 12:19:28 -08:00
$(NULL)
build: split EXTRA_DIST files in src/ off from DISTFILES and handle separately This is again to avoid the "Argument list too long" error we are hitting more and more now. Given we just merged elementary, emotion generic players, evas generic loaders and elm_code it is not surprising we are hitting it again. This time the number of files being hold in DISTFILES has just grown to big so a make dist was no longer possible. If one looks at what the DISTFILES variable from automake holds you can image it grows a lot with all the source files plus generated files we have in tree now. DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) To cut off a big chunk but still keep all the other automagic in place for SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle the files in a dist-hook now. Another thing to note here is that this also only happens as we have the one big Makefile with includes. If we go back to per directory Makefiles this problem should vanish as well. In any case we need a solution for 1.18 now and this is what I have to offer. If you have a cleaner solution in mind feel welcome to test it out and if everything we need keeps working (make, make examples, make check, make benchmark, make dist and make distcheck) go ahead.
2016-06-08 01:26:06 -07:00
EXTRA_DIST2 += \
Evas 3D: Fix distcheck build 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
2015-02-19 06:29:50 -08:00
modules/evas/engines/gl_common/shader_3d/gen_shaders_3d.sh \
evas: Fix regeneration of shaders (normal and 3d) This will trigger a re-run of the shaders shell scripts even in case of out-of-tree builds. BUILT_SOURCES is used here because for whatever reason make does not rebuild the .x targets in case of out-of-tree builds (even if the timestamps of the dependencies have changed).
2016-06-19 22:47:39 -07:00
modules/evas/engines/gl_common/shader_3d/include.shd \
Evas 3D: Fix distcheck build 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
2015-02-19 06:29:50 -08:00
$(GL_SHADERS_3D_GEN)
evas: Evas_3D - refactor shader system. Reviewers: Hermet, raster, jpeg, cedric Subscribers: artem.popov, cedric Differential Revision: https://phab.enlightenment.org/D1947 Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
2015-02-18 12:19:28 -08:00
evas: (Try to) fix shaders gen without breaking everything So... adding the .x files to BUILT_SOURCES means they would get deleted during clean. This was bad, but turned to be awful when this made the check for writability fail. See: 8a273158788d630e56b4dc14cdd44f0eaae6b7b5 2b8912462e0ec81efb8e30a63383b811f52e16f5 This commit reverts: 0b69356f1bbceab3261835bc2d4632f8f4669206 Notes: Please revert if this breaks the build for anyone. I'm pretty sure the use of top_srcdir is not recommended the way I've done it. I hate autofoo.
2016-06-23 22:36:10 -07:00
modules/evas/engines/gl_common/shader_3d/evas_gl_3d_shaders.x: $(top_srcdir)/src/modules/evas/engines/gl_common/shader_3d/gen_shaders_3d.sh $(GL_SHADERS_3D_GEN) $(top_srcdir)/src/modules/evas/engines/gl_common/shader_3d/include.shd
evas: Make shaders regen an opt-in behaviour While the shaders automatic regeneration is very useful when working on shaders, it has been the source of too many build breaks. So I'm making this regeneration an opt-in. You work on shaders? Set the env var EFL_SHD_REGEN=1
2016-06-27 00:00:50 -07:00
@if [ "x$(EFL_SHD_REGEN)" = "x1" ] ; then \
echo " SHADERS $@" ; \
sh $(top_srcdir)/src/modules/evas/engines/gl_common/shader_3d/gen_shaders_3d.sh $(GL_SHADERS_3D_GEN) ; \
fi
evas: (Try to) fix shaders gen without breaking everything So... adding the .x files to BUILT_SOURCES means they would get deleted during clean. This was bad, but turned to be awful when this made the check for writability fail. See: 8a273158788d630e56b4dc14cdd44f0eaae6b7b5 2b8912462e0ec81efb8e30a63383b811f52e16f5 This commit reverts: 0b69356f1bbceab3261835bc2d4632f8f4669206 Notes: Please revert if this breaks the build for anyone. I'm pretty sure the use of top_srcdir is not recommended the way I've done it. I hate autofoo.
2016-06-23 22:36:10 -07:00
modules/evas/engines/gl_common/evas_gl_3d_shader.c: modules/evas/engines/gl_common/shader_3d/evas_gl_3d_shaders.x
evas: Evas_3D - refactor shader system. Reviewers: Hermet, raster, jpeg, cedric Subscribers: artem.popov, cedric Differential Revision: https://phab.enlightenment.org/D1947 Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
2015-02-18 12:19:28 -08:00
autotools: turn on build for gl_generic backend.
2014-07-11 06:15:42 -07:00
GL_GENERIC_SOURCES = \
evas/engine_gl_generic: Make sure we epend on the needed header for compiling. Fixup for a3a15b1986392bcc48affbab5c502013a83bfddd which removed the header from installation. We need to have it in SOURCES now during distcheck.
2014-07-29 08:05:30 -07:00
modules/evas/engines/gl_generic/evas_engine.c \
Ector GL: Add skeletton for Evas.Ector.GL.Image.Buffer This is an ector buffer backed by an existing Evas_GL_Image
2015-12-17 01:04:06 -08:00
modules/evas/engines/gl_generic/Evas_Engine_GL_Generic.h \
evas: Fix compilation after @cedric's "fix" Don't forget git add!
2016-12-08 17:48:35 -08:00
modules/evas/engines/gl_generic/Evas_Engine_GL_Shared.h \
evas: Fix crash with filters Since the EO APIs are defined as weak symbols, invalid definitions of EAPI lead to runtime crashes on non-public APIs. This is a fix following a series of changes wrt. EAPI definitions.
2017-08-15 22:06:51 -07:00
modules/evas/engines/gl_generic/evas_ector_gl.h \
Ector GL: Add skeletton for Evas.Ector.GL.Image.Buffer This is an ector buffer backed by an existing Evas_GL_Image
2015-12-17 01:04:06 -08:00
modules/evas/engines/gl_generic/evas_ector_gl_buffer.c \
Evas filters: Add GL buffer backed by RGBA_Image Dumb implementation of a "smart" buffer capable of wrapping an RGBA_Image but that can still be rendered on screen (ie, an Evas_GL_Image is attached to it).
2016-01-04 00:48:48 -08:00
modules/evas/engines/gl_generic/evas_ector_gl_image_buffer.c \
evas filters: Prepare GL support for blend operation No implementation yet, this is just the skeletton!
2017-01-17 04:34:48 -08:00
modules/evas/engines/gl_generic/filters/gl_engine_filter.h \
modules/evas/engines/gl_generic/filters/gl_filter_blend.c \
evas filter: Implement blur filter in pure GL Wait a second though, this implementation is not only incomplete (no support for box vs. gaussian blur), it's also insanely bad in terms of performance. Small radii may work fine, but at least blurs render properly in GL with this patch (no more glReadPixels!). The shader needs a lot of love, including in particular: - support for 1D box blur single pass - support for 1D gaussian (or sine) blur - use linear interpolation and N-tap filters - separation of 2D blur in two passes (high-level logic) - potentially separation of large 1D blurs in 2 or more passes knowing that 2sigma == sigma + sigma when it comes to the gaussian bell curve.
2017-01-25 01:06:29 -08:00
modules/evas/engines/gl_generic/filters/gl_filter_blur.c \
evas filters: Implement displace filter in pure GL This one was a bit more... "fun". I had to add a new vertex attribute and obviously using a VertexAttribPointer led to incomprehensible crashes. But a simple glVertexAttrib2fv makes it work like a charm! A rare option is not handled yet.
2017-01-23 22:28:18 -08:00
modules/evas/engines/gl_generic/filters/gl_filter_curve.c \
modules/evas/engines/gl_generic/filters/gl_filter_displace.c \
evas filters: Implement fill filter in pure GL Now that one was trivial. Could also be done with glClear and glScissor instead, but the rectangle infrastructure works well enough.
2017-01-23 22:39:29 -08:00
modules/evas/engines/gl_generic/filters/gl_filter_fill.c \
evas filters: Implement mask filter in pure GL This reuses the existing mask infrastructure, but adds a color flag to use the whole RGBA range, rather than just the Alpha channel. Filters are still very slow (glReadPixels and non-optimized use of GL buffers...), but this is progress :)
2017-01-23 21:23:03 -08:00
modules/evas/engines/gl_generic/filters/gl_filter_mask.c \
Ector GL: Add skeletton for Evas.Ector.GL.Image.Buffer This is an ector buffer backed by an existing Evas_GL_Image
2015-12-17 01:04:06 -08:00
$(NULL)
evas_gl_generic_eolian_files = \
modules/evas/engines/gl_generic/evas_ector_gl_buffer.eo \
modules/evas/engines/gl_generic/evas_ector_gl_image_buffer.eo \
$(NULL)
evas_gl_generic_eolian_c = $(evas_gl_generic_eolian_files:%.eo=%.eo.c)
evas_gl_generic_eolian_h = $(evas_gl_generic_eolian_files:%.eo=%.eo.h) \
$(evas_gl_generic_eolian_files:%.eo=%.eo.legacy.h) \
$(evas_gl_generic_eolian_type_files:%.eot=%.eot.h)
BUILT_SOURCES += \
$(evas_gl_generic_eolian_c) \
evas: Fix regeneration of shaders (normal and 3d) This will trigger a re-run of the shaders shell scripts even in case of out-of-tree builds. BUILT_SOURCES is used here because for whatever reason make does not rebuild the .x targets in case of out-of-tree builds (even if the timestamps of the dependencies have changed).
2016-06-19 22:47:39 -07:00
$(evas_gl_generic_eolian_h) \
evas: (Try to) fix shaders gen without breaking everything So... adding the .x files to BUILT_SOURCES means they would get deleted during clean. This was bad, but turned to be awful when this made the check for writability fail. See: 8a273158788d630e56b4dc14cdd44f0eaae6b7b5 2b8912462e0ec81efb8e30a63383b811f52e16f5 This commit reverts: 0b69356f1bbceab3261835bc2d4632f8f4669206 Notes: Please revert if this breaks the build for anyone. I'm pretty sure the use of top_srcdir is not recommended the way I've done it. I hate autofoo.
2016-06-23 22:36:10 -07:00
$(NULL)
Ector GL: Add skeletton for Evas.Ector.GL.Image.Buffer This is an ector buffer backed by an existing Evas_GL_Image
2015-12-17 01:04:06 -08:00
build: split EXTRA_DIST files in src/ off from DISTFILES and handle separately This is again to avoid the "Argument list too long" error we are hitting more and more now. Given we just merged elementary, emotion generic players, evas generic loaders and elm_code it is not surprising we are hitting it again. This time the number of files being hold in DISTFILES has just grown to big so a make dist was no longer possible. If one looks at what the DISTFILES variable from automake holds you can image it grows a lot with all the source files plus generated files we have in tree now. DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) To cut off a big chunk but still keep all the other automagic in place for SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle the files in a dist-hook now. Another thing to note here is that this also only happens as we have the one big Makefile with includes. If we go back to per directory Makefiles this problem should vanish as well. In any case we need a solution for 1.18 now and this is what I have to offer. If you have a cleaner solution in mind feel welcome to test it out and if everything we need keeps working (make, make examples, make check, make benchmark, make dist and make distcheck) go ahead.
2016-06-08 01:26:06 -07:00
EXTRA_DIST2 += $(evas_gl_generic_eolian_files)
Evas filters: Final fix after the ector refactor This implements a generic way of scaling buffers, using fake RGBA_Image wrapping ector buffer maps. The underlying algo is still the good old linear sw scaler. Now the filters *should* be back to their previous level of usability. Performance will probably be even worse than it was before, for GL, as more glReadPixels may be involved. Optimization now consists in actually implementing the filters with GL shaders.
2016-01-04 04:46:56 -08:00
Ector GL: Add skeletton for Evas.Ector.GL.Image.Buffer This is an ector buffer backed by an existing Evas_GL_Image
2015-12-17 01:04:06 -08:00
#evaseolianfilesdir = $(datadir)/eolian/include/evas-@VMAJ@
#evaseolianfiles_DATA += $(evas_gl_generic_eolian_files)
autotools: turn on build for gl_generic backend.
2014-07-11 06:15:42 -07:00
evas: (Try to) fix shaders gen without breaking everything So... adding the .x files to BUILT_SOURCES means they would get deleted during clean. This was bad, but turned to be awful when this made the check for writability fail. See: 8a273158788d630e56b4dc14cdd44f0eaae6b7b5 2b8912462e0ec81efb8e30a63383b811f52e16f5 This commit reverts: 0b69356f1bbceab3261835bc2d4632f8f4669206 Notes: Please revert if this breaks the build for anyone. I'm pretty sure the use of top_srcdir is not recommended the way I've done it. I hate autofoo.
2016-06-23 22:36:10 -07:00
if BUILD_ENGINE_GL_COMMON
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
if EVAS_STATIC_BUILD_GL_COMMON
autotools: turn on build for gl_generic backend.
2014-07-11 06:15:42 -07:00
lib_evas_libevas_la_SOURCES += $(GL_COMMON_SOURCES) $(GL_GENERIC_SOURCES)
merge: evas fixes * gl engines were checking for eet module, which does not exist when we install first the efl package. * fix pkgconfig values for static linking * add Evas output to configure SVN revision: 78918
2012-11-05 01:25:44 -08:00
lib_evas_libevas_la_LIBADD += @evas_engine_gl_common_libs@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
else
efl/evas: Fix using sse3 for all files We need to pass -sse3 to compile only in the file that checks for SSE3. Otherwise even for plain C compiler is free to use sse3 instructions. But they won't work if the CPU doesn't support it and therefore will SIGILL. SVN revision: 78973
2012-11-07 09:37:35 -08:00
noinst_LTLIBRARIES += modules/evas/engines/gl_common/libevas_engine_gl_common.la
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_gl_common_libevas_engine_gl_common_la_SOURCES = $(GL_COMMON_SOURCES)
add a global Efl_Config.h for everyone. * ned to replicate changes in other .pc.in files * need to replicate changes in other E*.h installed header files
2013-04-24 07:43:33 -07:00
modules_evas_engines_gl_common_libevas_engine_gl_common_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
-I$(top_srcdir)/src/lib/evas/cserve2 \
@EVAS_CFLAGS@
autotools: turn on build for gl_generic backend.
2014-07-11 06:15:42 -07:00
# The generic backend for GL
engineglgenericpkgdir = $(libdir)/evas/modules/engines/gl_generic/$(MODULE_ARCH)
engineglgenericpkg_LTLIBRARIES = modules/evas/engines/gl_generic/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_engineglgenericpkgLTLIBRARIES = install-engineglgenericpkgLTLIBRARIES
$(install_engineglgenericpkgLTLIBRARIES): install-libLTLIBRARIES
autotools: turn on build for gl_generic backend.
2014-07-11 06:15:42 -07:00
modules_evas_engines_gl_generic_module_la_SOURCES = $(GL_GENERIC_SOURCES)
modules_evas_engines_gl_generic_module_la_CFLAGS = \
-I$(top_builddir)/src/lib/efl \
-I$(top_srcdir)/src/lib/evas/include \
Ector GL: Add skeletton for Evas.Ector.GL.Image.Buffer This is an ector buffer backed by an existing Evas_GL_Image
2015-12-17 01:04:06 -08:00
-I$(top_builddir)/src/lib/evas/include \
autotools: turn on build for gl_generic backend.
2014-07-11 06:15:42 -07:00
-I$(top_srcdir)/src/lib/evas/cserve2 \
evas filters: Prepare GL support for blend operation No implementation yet, this is just the skeletton!
2017-01-17 04:34:48 -08:00
-I$(top_srcdir)/src/lib/evas/filters \
-I$(top_builddir)/src/lib/evas/canvas \
autotools: turn on build for gl_generic backend.
2014-07-11 06:15:42 -07:00
-I$(top_srcdir)/src/modules/evas/engines/gl_common \
evas: fix make distcheck.
2015-04-03 07:33:53 -07:00
-I$(top_builddir)/src/modules/evas/engines/gl_generic \
autotools: fix compiling/linking gl engines on OSX. 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>
2014-12-03 00:45:51 -08:00
@evas_engine_gl_common_cflags@ \
autotools: turn on build for gl_generic backend.
2014-07-11 06:15:42 -07:00
@EVAS_CFLAGS@
modules_evas_engines_gl_generic_module_la_LIBADD = \
modules/evas/engines/gl_common/libevas_engine_gl_common.la \
@evas_engine_gl_common_libs@ \
@USE_EVAS_LIBS@
modules_evas_engines_gl_generic_module_la_DEPENDENCIES = \
@USE_EVAS_INTERNAL_LIBS@ \
modules/evas/engines/gl_common/libevas_engine_gl_common.la
modules_evas_engines_gl_generic_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_engines_gl_generic_module_la_LIBTOOLFLAGS = --tag=disable-static
efl: improve X detection by Joel Klinghed. * Split out ecore_imf_xim to do its own check * Fixed problem with xcb's makekeys, no rule for $(top_builddir)/src/utils/ecore/makekeys$(EXEEXT) exists so make used an implicit rule (ignoring any cflags of course) * Fixed gl_x11 engine to build with either Xlib or XCB (xcb flags were missing) * Added EFL_FIND_X and replace any used of AC_PATH_X{,TRA}. First looks for Xorg pkg-config files then if those arn't found it falls back to old AC_PATH_X. Also generalized common header and lib checks. Could probably use some polishing (the AC_CACHE_VAL cruft especially) but this is what I have time for tonight. Now X11 should be found on non-standard locations by means of xmkmf, --x-includes/--x-libraries and also pkg-config. SVN revision: 82475
2013-01-09 08:48:40 -08:00
if BUILD_ENGINE_GL_X11
remove xcb support in ecore_x and evas engines as per mailing list as per mailing list discussion about dropping xcb support now. it hasn't been complete for a long time, thus not recommented for being turned on. as we are moving to a wayland world xcbmakes even less sense. as agreed, time to clean up a bit and remove a distraction as well as not well tested code. this also updates po's too. @feature
2016-11-01 07:04:47 -07:00
modules_evas_engines_gl_common_libevas_engine_gl_common_la_CPPFLAGS += @evas_engine_gl_xlib_cflags@
efl: improve X detection by Joel Klinghed. * Split out ecore_imf_xim to do its own check * Fixed problem with xcb's makekeys, no rule for $(top_builddir)/src/utils/ecore/makekeys$(EXEEXT) exists so make used an implicit rule (ignoring any cflags of course) * Fixed gl_x11 engine to build with either Xlib or XCB (xcb flags were missing) * Added EFL_FIND_X and replace any used of AC_PATH_X{,TRA}. First looks for Xorg pkg-config files then if those arn't found it falls back to old AC_PATH_X. Also generalized common header and lib checks. Could probably use some polishing (the AC_CACHE_VAL cruft especially) but this is what I have time for tonight. Now X11 should be found on non-standard locations by means of xmkmf, --x-includes/--x-libraries and also pkg-config. SVN revision: 82475
2013-01-09 08:48:40 -08:00
endif
evas-wayland-egl: Fix segmentation fault on dynamic loaded gl related functions. 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
2014-08-15 06:17:25 -07:00
if BUILD_ENGINE_WAYLAND_EGL
modules_evas_engines_gl_common_libevas_engine_gl_common_la_CPPFLAGS += @evas_engine_wayland_egl_cflags@
endif
evas: add evas gl-drm engine 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>
2014-08-21 02:22:16 -07:00
if BUILD_ENGINE_GL_DRM
modules_evas_engines_gl_common_libevas_engine_gl_common_la_CPPFLAGS += @evas_engine_gl_drm_cflags@
endif
evas: add eglfs evas module. 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>
2016-03-18 00:56:59 -07:00
if BUILD_ENGINE_EGLFS
modules_evas_engines_gl_common_libevas_engine_gl_common_la_CPPFLAGS += @evas_engine_eglfs_cflags@
endif
evas-gl_cocoa: migrate to gl_generic infrastructure It has been a long journey, but here we are at last... The infamous gl_cocoa engine has been migrated to the gl_generic infrastructure. This should provide great improvements and hopefully reduce side-channels b0rkage. Fonts seems better, scrolling is smoother, expedite does not segfault anymore... I haven't found a regression with elementary_test, elementary_config, terminology, expedite.
2016-08-24 08:58:29 -07:00
if BUILD_ENGINE_GL_COCOA
modules_evas_engines_gl_common_libevas_engine_gl_common_la_CPPFLAGS += @evas_engine_gl_cocoa_cflags@
endif
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
modules_evas_engines_gl_common_libevas_engine_gl_common_la_LIBADD = @USE_EVAS_LIBS@
modules_evas_engines_gl_common_libevas_engine_gl_common_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
efl: unbreak last commit. seems that automake will parse LDFLAGS for -module and if it's not present it will complain about name not starting with 'lib'. seems my last try was without NOCONFIGURE=1 and autogen continued to the old ./configure, that printed lots of messages and the error went unnoticed SVN revision: 81917
2012-12-30 17:13:47 -08:00
modules_evas_engines_gl_common_libevas_engine_gl_common_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_gl_common_libevas_engine_gl_common_la_LIBTOOLFLAGS = --tag=disable-static
endif
endif
if BUILD_ENGINE_GL_COCOA
GL_COCOA_SOURCES = \
modules/evas/engines/gl_cocoa/evas_engine.c \
evas-gl_cocoa: start refactoring for gl_generic
2016-08-24 03:12:59 -07:00
modules/evas/engines/gl_cocoa/evas_outbuf.m \
evas-gl_cocoa: migrate to gl_generic infrastructure It has been a long journey, but here we are at last... The infamous gl_cocoa engine has been migrated to the gl_generic infrastructure. This should provide great improvements and hopefully reduce side-channels b0rkage. Fonts seems better, scrolling is smoother, expedite does not segfault anymore... I haven't found a regression with elementary_test, elementary_config, terminology, expedite.
2016-08-24 08:58:29 -07:00
modules/evas/engines/gl_cocoa/evas_engine.h \
modules/evas/engines/gl_cocoa/Evas_Engine_GL_Cocoa.h
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
if EVAS_STATIC_BUILD_GL_COCOA
lib_evas_libevas_la_SOURCES += $(GL_COCOA_SOURCES)
evas-gl_cocoa: migrate to gl_generic infrastructure It has been a long journey, but here we are at last... The infamous gl_cocoa engine has been migrated to the gl_generic infrastructure. This should provide great improvements and hopefully reduce side-channels b0rkage. Fonts seems better, scrolling is smoother, expedite does not segfault anymore... I haven't found a regression with elementary_test, elementary_config, terminology, expedite.
2016-08-24 08:58:29 -07:00
lib_evas_libevas_la_CPPFLAGS += @evas_engine_gl_cocoa_cflags@
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
lib_evas_libevas_la_LIBADD += @evas_engine_gl_cocoa_libs@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
else
engineglcocoapkgdir = $(libdir)/evas/modules/engines/gl_cocoa/$(MODULE_ARCH)
engineglcocoapkg_LTLIBRARIES = modules/evas/engines/gl_cocoa/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_engineglcocoapkgLTLIBRARIES = install-engineglcocoapkgLTLIBRARIES
$(install_engineglcocoapkgLTLIBRARIES): install-libLTLIBRARIES
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_gl_cocoa_module_la_SOURCES = $(GL_COCOA_SOURCES)
add a global Efl_Config.h for everyone. * ned to replicate changes in other .pc.in files * need to replicate changes in other E*.h installed header files
2013-04-24 07:43:33 -07:00
modules_evas_engines_gl_cocoa_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
-I$(top_srcdir)/src/lib/evas/cserve2 \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@EVAS_CFLAGS@ \
@evas_engine_gl_cocoa_cflags@
evas-gl_cocoa: migrate to gl_generic infrastructure It has been a long journey, but here we are at last... The infamous gl_cocoa engine has been migrated to the gl_generic infrastructure. This should provide great improvements and hopefully reduce side-channels b0rkage. Fonts seems better, scrolling is smoother, expedite does not segfault anymore... I haven't found a regression with elementary_test, elementary_config, terminology, expedite.
2016-08-24 08:58:29 -07:00
modules_evas_engines_gl_cocoa_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@evas_engine_gl_cocoa_libs@
evas_cocoa: build gl_common
2014-06-08 13:41:33 -07:00
modules_evas_engines_gl_cocoa_module_la_DEPENDENCIES = \
evas-gl_cocoa: migrate to gl_generic infrastructure It has been a long journey, but here we are at last... The infamous gl_cocoa engine has been migrated to the gl_generic infrastructure. This should provide great improvements and hopefully reduce side-channels b0rkage. Fonts seems better, scrolling is smoother, expedite does not segfault anymore... I haven't found a regression with elementary_test, elementary_config, terminology, expedite.
2016-08-24 08:58:29 -07:00
@USE_EVAS_INTERNAL_LIBS@
efl: unbreak last commit. seems that automake will parse LDFLAGS for -module and if it's not present it will complain about name not starting with 'lib'. seems my last try was without NOCONFIGURE=1 and autogen continued to the old ./configure, that printed lots of messages and the error went unnoticed SVN revision: 81917
2012-12-30 17:13:47 -08:00
modules_evas_engines_gl_cocoa_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_gl_cocoa_module_la_LIBTOOLFLAGS = --tag=disable-static
endif
endif
if BUILD_ENGINE_GL_SDL
GL_SDL_SOURCES = \
modules/evas/engines/gl_sdl/evas_engine.c \
evas: remove all Engine Info headers installation except for the buffer engine. We do not have any upstream application using those headers and if any do, they should have proper auto detection of them being available or not. Today, most application should use Ecore_Evas directly. If the need reappear, we will reintroduce those headers one by one.
2016-12-05 11:35:19 -08:00
modules/evas/engines/gl_sdl/evas_engine.h \
modules/evas/engines/gl_sdl/Evas_Engine_GL_SDL.h
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
if EVAS_STATIC_BUILD_GL_SDL
lib_evas_libevas_la_SOURCES += $(GL_SDL_SOURCES)
lib_evas_libevas_la_CPPFLAGS += \
-I$(top_srcdir)/src/modules/evas/engines/gl_common \
@evas_engine_gl_sdl_cflags@
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
lib_evas_libevas_la_LIBADD += @evas_engine_gl_sdl_libs@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
else
engineglsdlpkgdir = $(libdir)/evas/modules/engines/gl_sdl/$(MODULE_ARCH)
engineglsdlpkg_LTLIBRARIES = modules/evas/engines/gl_sdl/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_engineglsdlpkgLTLIBRARIES = install-engineglsdlpkgLTLIBRARIES
$(install_engineglsdlpkgLTLIBRARIES): install-libLTLIBRARIES
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_gl_sdl_module_la_SOURCES = $(GL_SDL_SOURCES)
add a global Efl_Config.h for everyone. * ned to replicate changes in other .pc.in files * need to replicate changes in other E*.h installed header files
2013-04-24 07:43:33 -07:00
modules_evas_engines_gl_sdl_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
-I$(top_srcdir)/src/lib/evas/cserve2 \
-I$(top_srcdir)/src/modules/evas/engines/gl_common \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@EVAS_CFLAGS@ \
@evas_engine_gl_sdl_cflags@
evas: move to SDL2 and use GL_Generic infrastructure.
2014-07-25 11:23:42 -07:00
modules_evas_engines_gl_sdl_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@evas_engine_gl_sdl_libs@
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
modules_evas_engines_gl_sdl_module_la_DEPENDENCIES = \
evas: move to SDL2 and use GL_Generic infrastructure.
2014-07-25 11:23:42 -07:00
@USE_EVAS_INTERNAL_LIBS@
efl: unbreak last commit. seems that automake will parse LDFLAGS for -module and if it's not present it will complain about name not starting with 'lib'. seems my last try was without NOCONFIGURE=1 and autogen continued to the old ./configure, that printed lots of messages and the error went unnoticed SVN revision: 81917
2012-12-30 17:13:47 -08:00
modules_evas_engines_gl_sdl_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_gl_sdl_module_la_LIBTOOLFLAGS = --tag=disable-static
endif
endif
if BUILD_ENGINE_GL_X11
GL_X11_SOURCES = \
modules/evas/engines/gl_x11/evas_engine.c \
modules/evas/engines/gl_x11/evas_x_main.c \
evas: remove all Engine Info headers installation except for the buffer engine. We do not have any upstream application using those headers and if any do, they should have proper auto detection of them being available or not. Today, most application should use Ecore_Evas directly. If the need reappear, we will reintroduce those headers one by one.
2016-12-05 11:35:19 -08:00
modules/evas/engines/gl_x11/evas_engine.h \
modules/evas/engines/gl_x11/Evas_Engine_GL_X11.h
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
if EVAS_STATIC_BUILD_GL_X11
lib_evas_libevas_la_SOURCES += $(GL_X11_SOURCES)
remove xcb support in ecore_x and evas engines as per mailing list as per mailing list discussion about dropping xcb support now. it hasn't been complete for a long time, thus not recommented for being turned on. as we are moving to a wayland world xcbmakes even less sense. as agreed, time to clean up a bit and remove a distraction as well as not well tested code. this also updates po's too. @feature
2016-11-01 07:04:47 -07:00
lib_evas_libevas_la_CPPFLAGS += @evas_engine_gl_xlib_cflags@
lib_evas_libevas_la_LIBADD += @evas_engine_gl_xlib_libs@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
else
engineglx11pkgdir = $(libdir)/evas/modules/engines/gl_x11/$(MODULE_ARCH)
engineglx11pkg_LTLIBRARIES = modules/evas/engines/gl_x11/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_engineglx11pkgLTLIBRARIES = install-engineglx11pkgLTLIBRARIES
$(install_engineglx11pkgLTLIBRARIES): install-libLTLIBRARIES
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_gl_x11_module_la_SOURCES = $(GL_X11_SOURCES)
add a global Efl_Config.h for everyone. * ned to replicate changes in other .pc.in files * need to replicate changes in other E*.h installed header files
2013-04-24 07:43:33 -07:00
modules_evas_engines_gl_x11_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
-I$(top_srcdir)/src/lib/evas/cserve2 \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@EVAS_CFLAGS@ \
remove xcb support in ecore_x and evas engines as per mailing list as per mailing list discussion about dropping xcb support now. it hasn't been complete for a long time, thus not recommented for being turned on. as we are moving to a wayland world xcbmakes even less sense. as agreed, time to clean up a bit and remove a distraction as well as not well tested code. this also updates po's too. @feature
2016-11-01 07:04:47 -07:00
@evas_engine_gl_xlib_cflags@
autotools: turn on build for gl_generic backend.
2014-07-11 06:15:42 -07:00
modules_evas_engines_gl_x11_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
remove xcb support in ecore_x and evas engines as per mailing list as per mailing list discussion about dropping xcb support now. it hasn't been complete for a long time, thus not recommented for being turned on. as we are moving to a wayland world xcbmakes even less sense. as agreed, time to clean up a bit and remove a distraction as well as not well tested code. this also updates po's too. @feature
2016-11-01 07:04:47 -07:00
@evas_engine_gl_xlib_libs@
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
modules_evas_engines_gl_x11_module_la_DEPENDENCIES = \
autotools: turn on build for gl_generic backend.
2014-07-11 06:15:42 -07:00
@USE_EVAS_INTERNAL_LIBS@
efl: unbreak last commit. seems that automake will parse LDFLAGS for -module and if it's not present it will complain about name not starting with 'lib'. seems my last try was without NOCONFIGURE=1 and autogen continued to the old ./configure, that printed lots of messages and the error went unnoticed SVN revision: 81917
2012-12-30 17:13:47 -08:00
modules_evas_engines_gl_x11_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_gl_x11_module_la_LIBTOOLFLAGS = --tag=disable-static
endif
endif
if BUILD_ENGINE_SOFTWARE_DDRAW
SOFTWARE_DDRAW_SOURCES = \
modules/evas/engines/software_ddraw/evas_engine.c \
modules/evas/engines/software_ddraw/evas_outbuf.c \
modules/evas/engines/software_ddraw/evas_ddraw_buffer.c \
modules/evas/engines/software_ddraw/evas_ddraw_main.cpp \
evas: remove all Engine Info headers installation except for the buffer engine. We do not have any upstream application using those headers and if any do, they should have proper auto detection of them being available or not. Today, most application should use Ecore_Evas directly. If the need reappear, we will reintroduce those headers one by one.
2016-12-05 11:35:19 -08:00
modules/evas/engines/software_ddraw/evas_engine.h \
modules/evas/engines/software_ddraw/Evas_Engine_Software_DDraw.h
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
if EVAS_STATIC_BUILD_SOFTWARE_DDRAW
lib_evas_libevas_la_SOURCES += $(SOFTWARE_DDRAW_SOURCES)
lib_evas_libevas_la_CPPFLAGS += @evas_engine_software_ddraw_cflags@
lib_evas_libevas_la_CXXFLAGS += -fno-rtti -fno-exceptions
lib_evas_libevas_la_LIBADD += @evas_engine_software_ddraw_libs@
else
enginesoftwareddrawpkgdir = $(libdir)/evas/modules/engines/software_ddraw/$(MODULE_ARCH)
enginesoftwareddrawpkg_LTLIBRARIES = modules/evas/engines/software_ddraw/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_enginesoftwareddrawpkgLTLIBRARIES = install-enginesoftwareddrawpkgLTLIBRARIES
$(install_enginesoftwareddrawpkgLTLIBRARIES): install-libLTLIBRARIES
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_software_ddraw_module_la_SOURCES = $(SOFTWARE_DDRAW_SOURCES)
add a global Efl_Config.h for everyone. * ned to replicate changes in other .pc.in files * need to replicate changes in other E*.h installed header files
2013-04-24 07:43:33 -07:00
modules_evas_engines_software_ddraw_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
-I$(top_srcdir)/src/lib/evas/cserve2 \
efl: simplify linkage/usage of evil on windows. instead of spreading it all around, just define 2 AC_SUBST() that will do the work. SVN revision: 81477
2012-12-20 11:25:51 -08:00
@EVAS_CFLAGS@ \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@evas_engine_software_ddraw_cflags@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_software_ddraw_module_la_CXXFLAGS = -fno-rtti -fno-exceptions
modules_evas_engines_software_ddraw_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
efl: refactor CFLAGS, LIBS, LIBADD and LDADD usage. - remove EFL_LIBS and EFL_CFLAGS, use per-lib values that inherit from EFL (general) - add NAME_LDFLAGS and EFL_LDFLAGS for linker flags. - LDADD (binaries) now use NAME_LDFLAGS instead of NAME_LIBS, as they link to libname.la and that will pull in the libtool dependencies SVN revision: 81915
2012-12-30 16:46:14 -08:00
@evas_engine_software_ddraw_libs@
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
modules_evas_engines_software_ddraw_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
efl: unbreak last commit. seems that automake will parse LDFLAGS for -module and if it's not present it will complain about name not starting with 'lib'. seems my last try was without NOCONFIGURE=1 and autogen continued to the old ./configure, that printed lots of messages and the error went unnoticed SVN revision: 81917
2012-12-30 17:13:47 -08:00
modules_evas_engines_software_ddraw_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_software_ddraw_module_la_LIBTOOLFLAGS = --tag=disable-static
endif
endif
if BUILD_ENGINE_SOFTWARE_GDI
SOFTWARE_GDI_SOURCES = \
modules/evas/engines/software_gdi/evas_engine.c \
modules/evas/engines/software_gdi/evas_outbuf.c \
modules/evas/engines/software_gdi/evas_gdi_buffer.c \
modules/evas/engines/software_gdi/evas_gdi_main.c \
evas: remove all Engine Info headers installation except for the buffer engine. We do not have any upstream application using those headers and if any do, they should have proper auto detection of them being available or not. Today, most application should use Ecore_Evas directly. If the need reappear, we will reintroduce those headers one by one.
2016-12-05 11:35:19 -08:00
modules/evas/engines/software_gdi/evas_engine.h \
modules/evas/engines/software_gdi/Evas_Engine_Software_Gdi.h
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
if EVAS_STATIC_BUILD_SOFTWARE_GDI
lib_evas_libevas_la_SOURCES += $(SOFTWARE_GDI_SOURCES)
lib_evas_libevas_la_CPPFLAGS += @evas_engine_software_gdi_cflags@
lib_evas_libevas_la_LIBADD += @evas_engine_software_gdi_libs@
else
enginesoftwaregdipkgdir = $(libdir)/evas/modules/engines/software_gdi/$(MODULE_ARCH)
enginesoftwaregdipkg_LTLIBRARIES = modules/evas/engines/software_gdi/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_enginesoftwaregdipkgLTLIBRARIES = install-enginesoftwaregdipkgLTLIBRARIES
$(install_enginesoftwaregdipkgLTLIBRARIES): install-libLTLIBRARIES
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_software_gdi_module_la_SOURCES = $(SOFTWARE_GDI_SOURCES)
add a global Efl_Config.h for everyone. * ned to replicate changes in other .pc.in files * need to replicate changes in other E*.h installed header files
2013-04-24 07:43:33 -07:00
modules_evas_engines_software_gdi_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
-I$(top_srcdir)/src/lib/evas/cserve2 \
efl: simplify linkage/usage of evil on windows. instead of spreading it all around, just define 2 AC_SUBST() that will do the work. SVN revision: 81477
2012-12-20 11:25:51 -08:00
@EVAS_CFLAGS@ \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@evas_engine_software_gdi_cflags@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_software_gdi_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
efl: refactor CFLAGS, LIBS, LIBADD and LDADD usage. - remove EFL_LIBS and EFL_CFLAGS, use per-lib values that inherit from EFL (general) - add NAME_LDFLAGS and EFL_LDFLAGS for linker flags. - LDADD (binaries) now use NAME_LDFLAGS instead of NAME_LIBS, as they link to libname.la and that will pull in the libtool dependencies SVN revision: 81915
2012-12-30 16:46:14 -08:00
@evas_engine_software_gdi_libs@
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
modules_evas_engines_software_gdi_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
efl: unbreak last commit. seems that automake will parse LDFLAGS for -module and if it's not present it will complain about name not starting with 'lib'. seems my last try was without NOCONFIGURE=1 and autogen continued to the old ./configure, that printed lots of messages and the error went unnoticed SVN revision: 81917
2012-12-30 17:13:47 -08:00
modules_evas_engines_software_gdi_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_software_gdi_module_la_LIBTOOLFLAGS = --tag=disable-static
endif
endif
if BUILD_ENGINE_SOFTWARE_X11
SOFTWARE_X11_SOURCES = \
modules/evas/engines/software_x11/evas_engine.c \
this is the START of something.. disabled at runtime for now - the swapper infra is intended to have the ability to map pixels of backbuffers right in for total zero-copy updates. SVN revision: 79452
2012-11-19 05:43:48 -08:00
modules/evas/engines/software_x11/evas_engine.h \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules/evas/engines/software_x11/evas_x_egl.c \
evas: remove all Engine Info headers installation except for the buffer engine. We do not have any upstream application using those headers and if any do, they should have proper auto detection of them being available or not. Today, most application should use Ecore_Evas directly. If the need reappear, we will reintroduce those headers one by one.
2016-12-05 11:35:19 -08:00
modules/evas/engines/software_x11/evas_x_egl.h \
modules/evas/engines/software_x11/Evas_Engine_Software_X11.h
add a global Efl_Config.h for everyone. * ned to replicate changes in other .pc.in files * need to replicate changes in other E*.h installed header files
2013-04-24 07:43:33 -07:00
SOFTWARE_X11_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
-I$(top_srcdir)/src/lib/evas/cserve2 \
evas/software_x11: implement native surface set for x11 type 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>
2015-02-03 03:35:41 -08:00
@ECORE_X_CFLAGS@ \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@EVAS_CFLAGS@
SOFTWARE_X11_LIBADD =
if BUILD_ENGINE_SOFTWARE_XLIB
SOFTWARE_X11_SOURCES += \
this is the START of something.. disabled at runtime for now - the swapper infra is intended to have the ability to map pixels of backbuffers right in for total zero-copy updates. SVN revision: 79452
2012-11-19 05:43:48 -08:00
modules/evas/engines/software_x11/evas_xlib_swapbuf.c \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules/evas/engines/software_x11/evas_xlib_outbuf.c \
modules/evas/engines/software_x11/evas_xlib_buffer.c \
modules/evas/engines/software_x11/evas_xlib_color.c \
this is the START of something.. disabled at runtime for now - the swapper infra is intended to have the ability to map pixels of backbuffers right in for total zero-copy updates. SVN revision: 79452
2012-11-19 05:43:48 -08:00
modules/evas/engines/software_x11/evas_xlib_main.c \
modules/evas/engines/software_x11/evas_xlib_swapper.c \
evas/software_x11: implement native surface set for x11 type 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>
2015-02-03 03:35:41 -08:00
modules/evas/engines/software_x11/evas_xlib_image.c \
Evas software_x11: add DRI2-x11 support at image_native_set() Summary: add DRI2-x11 feature at image_native_set() on Software-x11 This is based on TBM, which means Tizen platform. Reviewers: spacegrapher, wonsik, raster, jpeg Subscribers: scholb.kim, dkdk, cedric Differential Revision: https://phab.enlightenment.org/D3291
2015-11-10 21:19:11 -08:00
modules/evas/engines/software_x11/evas_xlib_dri_image.c \
this is the START of something.. disabled at runtime for now - the swapper infra is intended to have the ability to map pixels of backbuffers right in for total zero-copy updates. SVN revision: 79452
2012-11-19 05:43:48 -08:00
modules/evas/engines/software_x11/evas_xlib_outbuf.h \
modules/evas/engines/software_x11/evas_xlib_swapbuf.h \
modules/evas/engines/software_x11/evas_xlib_buffer.h \
modules/evas/engines/software_x11/evas_xlib_color.h \
evas/software_x11: implement native surface set for x11 type 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>
2015-02-03 03:35:41 -08:00
modules/evas/engines/software_x11/evas_xlib_swapper.h \
Evas software_x11: add DRI2-x11 support at image_native_set() Summary: add DRI2-x11 feature at image_native_set() on Software-x11 This is based on TBM, which means Tizen platform. Reviewers: spacegrapher, wonsik, raster, jpeg Subscribers: scholb.kim, dkdk, cedric Differential Revision: https://phab.enlightenment.org/D3291
2015-11-10 21:19:11 -08:00
modules/evas/engines/software_x11/evas_xlib_image.h \
modules/evas/engines/software_x11/evas_xlib_dri_image.h
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
SOFTWARE_X11_CPPFLAGS += @evas_engine_software_xlib_cflags@
SOFTWARE_X11_LIBADD += @evas_engine_software_xlib_libs@
endif
if EVAS_STATIC_BUILD_SOFTWARE_X11
lib_evas_libevas_la_SOURCES += $(SOFTWARE_X11_SOURCES)
lib_evas_libevas_la_CPPFLAGS += $(SOFTWARE_X11_CPPFLAGS)
lib_evas_libevas_la_LIBADD += $(SOFTWARE_X11_LIBADD)
else
enginesoftwarex11pkgdir = $(libdir)/evas/modules/engines/software_x11/$(MODULE_ARCH)
enginesoftwarex11pkg_LTLIBRARIES = modules/evas/engines/software_x11/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_enginesoftwarex11pkgLTLIBRARIES = install-enginesoftwarex11pkgLTLIBRARIES
$(install_enginesoftwarex11pkgLTLIBRARIES): install-libLTLIBRARIES
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_software_x11_module_la_SOURCES = $(SOFTWARE_X11_SOURCES)
add a global Efl_Config.h for everyone. * ned to replicate changes in other .pc.in files * need to replicate changes in other E*.h installed header files
2013-04-24 07:43:33 -07:00
modules_evas_engines_software_x11_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl $(SOFTWARE_X11_CPPFLAGS)
evas/software_x11: implement native surface set for x11 type 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>
2015-02-03 03:35:41 -08:00
modules_evas_engines_software_x11_module_la_LIBADD = @USE_ECORE_X_LIBS@ @USE_EVAS_LIBS@ $(SOFTWARE_X11_LIBADD)
modules_evas_engines_software_x11_module_la_DEPENDENCIES = @USE_ECORE_X_INTERNAL_LIBS@ @USE_EVAS_INTERNAL_LIBS@
efl: unbreak last commit. seems that automake will parse LDFLAGS for -module and if it's not present it will complain about name not starting with 'lib'. seems my last try was without NOCONFIGURE=1 and autogen continued to the old ./configure, that printed lots of messages and the error went unnoticed SVN revision: 81917
2012-12-30 17:13:47 -08:00
modules_evas_engines_software_x11_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_software_x11_module_la_LIBTOOLFLAGS = --tag=disable-static
endif
endif
if BUILD_ENGINE_WAYLAND_EGL
WAYLAND_EGL_SOURCES = \
modules/evas/engines/wayland_egl/evas_engine.c \
modules/evas/engines/wayland_egl/evas_wl_main.c \
evas: remove all Engine Info headers installation except for the buffer engine. We do not have any upstream application using those headers and if any do, they should have proper auto detection of them being available or not. Today, most application should use Ecore_Evas directly. If the need reappear, we will reintroduce those headers one by one.
2016-12-05 11:35:19 -08:00
modules/evas/engines/wayland_egl/evas_engine.h \
modules/evas/engines/wayland_common/Evas_Engine_Wayland.h
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
if EVAS_STATIC_BUILD_WAYLAND_EGL
lib_evas_libevas_la_SOURCES += $(WAYLAND_EGL_SOURCES)
evas-wayland-egl: Fix segmentation fault on dynamic loaded gl related functions. 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
2014-08-15 06:17:25 -07:00
lib_evas_libevas_la_CPPFLAGS += @evas_engine_wayland_egl_cflags@
efl: refactor CFLAGS, LIBS, LIBADD and LDADD usage. - remove EFL_LIBS and EFL_CFLAGS, use per-lib values that inherit from EFL (general) - add NAME_LDFLAGS and EFL_LDFLAGS for linker flags. - LDADD (binaries) now use NAME_LDFLAGS instead of NAME_LIBS, as they link to libname.la and that will pull in the libtool dependencies SVN revision: 81915
2012-12-30 16:46:14 -08:00
lib_evas_libevas_la_LIBADD += @evas_engine_wayland_egl_libs@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
else
enginewaylandeglpkgdir = $(libdir)/evas/modules/engines/wayland_egl/$(MODULE_ARCH)
enginewaylandeglpkg_LTLIBRARIES = modules/evas/engines/wayland_egl/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_enginewaylandeglpkgLTLIBRARIES = install-enginewaylandeglpkgLTLIBRARIES
$(install_enginewaylandeglpkgLTLIBRARIES): install-libLTLIBRARIES
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_wayland_egl_module_la_SOURCES = $(WAYLAND_EGL_SOURCES)
add a global Efl_Config.h for everyone. * ned to replicate changes in other .pc.in files * need to replicate changes in other E*.h installed header files
2013-04-24 07:43:33 -07:00
modules_evas_engines_wayland_egl_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
-I$(top_srcdir)/src/lib/evas/cserve2 \
evas-wayland-egl: Fix segmentation fault on dynamic loaded gl related functions. 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
2014-08-15 06:17:25 -07:00
-I$(top_srcdir)/src/modules/evas/engines/wayland_egl \
wayland evas engines: share engine info structure These engines are incredibly similar - by sharing the same engine info structure we'll be able to simplify the wayland ecore_evas bits and make them much more maintainable.
2016-11-01 13:46:35 -07:00
-I$(top_srcdir)/src/modules/evas/engines/wayland_common \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@EVAS_CFLAGS@ \
wayland: Make the wayland evas engines dependent on ecore_wl2 Seems like the best place to put some common code.
2017-08-14 14:27:24 -07:00
@ECORE_WL2_CFLAGS@ \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@evas_engine_wayland_egl_cflags@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_wayland_egl_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
wayland: Make the wayland evas engines dependent on ecore_wl2 Seems like the best place to put some common code.
2017-08-14 14:27:24 -07:00
@USE_ECORE_WL2_LIBS@ \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@evas_engine_wayland_egl_libs@
evas - fix build dependencies that cause failed builds missing dev on ecore_wl2 so fix...
2017-08-21 00:04:01 -07:00
modules_evas_engines_wayland_egl_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@ lib/ecore_wl2/libecore_wl2.la
efl: unbreak last commit. seems that automake will parse LDFLAGS for -module and if it's not present it will complain about name not starting with 'lib'. seems my last try was without NOCONFIGURE=1 and autogen continued to the old ./configure, that printed lots of messages and the error went unnoticed SVN revision: 81917
2012-12-30 17:13:47 -08:00
modules_evas_engines_wayland_egl_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_wayland_egl_module_la_LIBTOOLFLAGS = --tag=disable-static
endif
endif
if BUILD_ENGINE_WAYLAND_SHM
WAYLAND_SHM_SOURCES = \
wayland evas engines: share engine info structure These engines are incredibly similar - by sharing the same engine info structure we'll be able to simplify the wayland ecore_evas bits and make them much more maintainable.
2016-11-01 13:46:35 -07:00
modules/evas/engines/wayland_common/Evas_Engine_Wayland.h \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules/evas/engines/wayland_shm/evas_engine.c \
Add new wayland shm engine files to Makefile. Signed-off-by: Christopher Michael <cp.michael@samsung.com> SVN revision: 83267
2013-01-24 01:18:26 -08:00
modules/evas/engines/wayland_shm/evas_engine.h \
wayland_shm/ecore_wl2: Move buffer allocation into ecore_wl2 This moves all the platform specific buffer allocation into ecore_wl2 instead of the engine. Note that this makes an internal struct available in the header. This will be removed shortly.
2017-11-13 14:26:09 -08:00
modules/evas/engines/wayland_shm/evas_outbuf.c
build: Fix screw up with wayland header auto generation
2017-02-01 09:29:40 -08:00
NODIST_WAYLAND_SHM_SOURCES = \
lib/ecore_wl2/linux-dmabuf-unstable-v1-protocol.c
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
if EVAS_STATIC_BUILD_WAYLAND_SHM
build: Fix screw up with wayland header auto generation
2017-02-01 09:29:40 -08:00
nodist_lib_evas_libevas_la_SOURCES = $(NODIST_WAYLAND_SHM_SOURCES)
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib_evas_libevas_la_SOURCES += $(WAYLAND_SHM_SOURCES)
wayland_shm/ecore_wl2: Move buffer allocation into ecore_wl2 This moves all the platform specific buffer allocation into ecore_wl2 instead of the engine. Note that this makes an internal struct available in the header. This will be removed shortly.
2017-11-13 14:26:09 -08:00
lib_evas_libevas_la_CPPFLAGS += @evas_engine_wayland_shm_cflags@
efl: refactor CFLAGS, LIBS, LIBADD and LDADD usage. - remove EFL_LIBS and EFL_CFLAGS, use per-lib values that inherit from EFL (general) - add NAME_LDFLAGS and EFL_LDFLAGS for linker flags. - LDADD (binaries) now use NAME_LDFLAGS instead of NAME_LIBS, as they link to libname.la and that will pull in the libtool dependencies SVN revision: 81915
2012-12-30 16:46:14 -08:00
lib_evas_libevas_la_LIBADD += @evas_engine_wayland_shm_libs@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
else
enginewaylandshmpkgdir = $(libdir)/evas/modules/engines/wayland_shm/$(MODULE_ARCH)
enginewaylandshmpkg_LTLIBRARIES = modules/evas/engines/wayland_shm/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_enginewaylandshmpkgLTLIBRARIES = install-enginewaylandshmpkgLTLIBRARIES
$(install_enginewaylandshmpkgLTLIBRARIES): install-libLTLIBRARIES
build: Fix screw up with wayland header auto generation
2017-02-01 09:29:40 -08:00
nodist_modules_evas_engines_wayland_shm_module_la_SOURCES = $(NODIST_WAYLAND_SHM_SOURCES)
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_wayland_shm_module_la_SOURCES = $(WAYLAND_SHM_SOURCES)
add a global Efl_Config.h for everyone. * ned to replicate changes in other .pc.in files * need to replicate changes in other E*.h installed header files
2013-04-24 07:43:33 -07:00
modules_evas_engines_wayland_shm_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
-I$(top_srcdir)/src/lib/evas/cserve2 \
wayland_shm: Add dmabuf to engine info Get the dmabuf protocol object from ecore_wl2 and store it in engine info
2016-04-11 14:10:33 -07:00
-I$(top_srcdir)/src/lib/ecore_wl2 \
ecore_wl2: Auto generate dmabuf protocol Remove the server protocol file as we don't need it here. Generally a trivial change as we have a recent version in tree with no weird changes.
2017-01-18 06:58:20 -08:00
-I$(top_builddir)/src/lib/ecore_wl2 \
wayland evas engines: share engine info structure These engines are incredibly similar - by sharing the same engine info structure we'll be able to simplify the wayland ecore_evas bits and make them much more maintainable.
2016-11-01 13:46:35 -07:00
-I$(top_srcdir)/src/modules/evas/engines/wayland_common \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@EVAS_CFLAGS@ \
wayland: Make the wayland evas engines dependent on ecore_wl2 Seems like the best place to put some common code.
2017-08-14 14:27:24 -07:00
@ECORE_WL2_CFLAGS@ \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@evas_engine_wayland_shm_cflags@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_wayland_shm_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
wayland: Make the wayland evas engines dependent on ecore_wl2 Seems like the best place to put some common code.
2017-08-14 14:27:24 -07:00
@USE_ECORE_WL2_LIBS@ \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@evas_engine_wayland_shm_libs@
evas - fix build dependencies that cause failed builds missing dev on ecore_wl2 so fix...
2017-08-21 00:04:01 -07:00
modules_evas_engines_wayland_shm_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@ lib/ecore_wl2/libecore_wl2.la
efl: unbreak last commit. seems that automake will parse LDFLAGS for -module and if it's not present it will complain about name not starting with 'lib'. seems my last try was without NOCONFIGURE=1 and autogen continued to the old ./configure, that printed lots of messages and the error went unnoticed SVN revision: 81917
2012-12-30 17:13:47 -08:00
modules_evas_engines_wayland_shm_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
modules_evas_engines_wayland_shm_module_la_LIBTOOLFLAGS = --tag=disable-static
endif
endif
Add drm engine build infrastructure. Signed-off-by: Chris Michael <cp.michael@samsung.com>
2013-04-29 04:35:08 -07:00
if BUILD_ENGINE_DRM
DRM_SOURCES = \
Add outbuf file to drm build. Signed-off-by: Chris Michael <cp.michael@samsung.com>
2013-04-29 23:16:55 -07:00
modules/evas/engines/drm/evas_outbuf.c \
Add drm engine build infrastructure. Signed-off-by: Chris Michael <cp.michael@samsung.com>
2013-04-29 04:35:08 -07:00
modules/evas/engines/drm/evas_engine.c \
evas-drm: Add Evas_Engine_Drm header to source files Signed-off-by: Chris Michael <cp.michael@samsung.com>
2014-02-12 05:52:10 -08:00
modules/evas/engines/drm/evas_engine.h \
modules/evas/engines/drm/Evas_Engine_Drm.h
Add drm engine build infrastructure. Signed-off-by: Chris Michael <cp.michael@samsung.com>
2013-04-29 04:35:08 -07:00
if EVAS_STATIC_BUILD_DRM
lib_evas_libevas_la_SOURCES += $(DRM_SOURCES)
lib_evas_libevas_la_CPPFLAGS += @evas_engine_drm_cflags@
lib_evas_libevas_la_LIBADD += @evas_engine_drm_libs@
else
enginedrmpkgdir = $(libdir)/evas/modules/engines/drm/$(MODULE_ARCH)
enginedrmpkg_LTLIBRARIES = modules/evas/engines/drm/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_enginedrmpkgLTLIBRARIES = install-enginedrmpkgLTLIBRARIES
$(install_enginedrmpkgLTLIBRARIES): install-libLTLIBRARIES
Add drm engine build infrastructure. Signed-off-by: Chris Michael <cp.michael@samsung.com>
2013-04-29 04:35:08 -07:00
modules_evas_engines_drm_module_la_SOURCES = $(DRM_SOURCES)
modules_evas_engines_drm_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
-I$(top_srcdir)/src/lib/evas/include \
-I$(top_srcdir)/src/lib/evas/cserve2 \
m4/evas_check_engine: Link evas drm engine to ecore-drm instead libdrm We now longer use libdrm directly in the evas drm engine thus we switch linking to ecore-drm.
2014-07-15 05:24:56 -07:00
-I$(top_srcdir)/src/modules/evas/engines/drm \
Add drm engine build infrastructure. Signed-off-by: Chris Michael <cp.michael@samsung.com>
2013-04-29 04:35:08 -07:00
@EVAS_CFLAGS@ \
evas-engines: Port evas drm engines to use Ecore_Drm2 library This patch ports the evas drm and gl_drm engines to use the new Ecore_Drm2 library Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
2016-05-03 09:02:20 -07:00
@ECORE_DRM2_CFLAGS@ \
Add drm engine build infrastructure. Signed-off-by: Chris Michael <cp.michael@samsung.com>
2013-04-29 04:35:08 -07:00
@evas_engine_drm_cflags@
modules_evas_engines_drm_module_la_LIBADD = \
@USE_EVAS_LIBS@ \
evas-engines: Port evas drm engines to use Ecore_Drm2 library This patch ports the evas drm and gl_drm engines to use the new Ecore_Drm2 library Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
2016-05-03 09:02:20 -07:00
@USE_ECORE_DRM2_LIBS@ \
evas: Fix improper extra library linkage for various engines The eglfs, drm and gl_drm engines were all linking to eeze internal libraries however none of those engines actually use eeze at all so we can remove the linking there. @fix Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
2016-04-26 07:02:35 -07:00
@evas_engine_drm_libs@
evas-engines: Port evas drm engines to use Ecore_Drm2 library This patch ports the evas drm and gl_drm engines to use the new Ecore_Drm2 library Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
2016-05-03 09:02:20 -07:00
modules_evas_engines_drm_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@ @USE_ECORE_DRM2_INTERNAL_LIBS@
Add drm engine build infrastructure. Signed-off-by: Chris Michael <cp.michael@samsung.com>
2013-04-29 04:35:08 -07:00
modules_evas_engines_drm_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_engines_drm_module_la_LIBTOOLFLAGS = --tag=disable-static
endif
endif
evas: add evas gl-drm engine 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>
2014-08-21 02:22:16 -07:00
if BUILD_ENGINE_GL_DRM
GL_DRM_SOURCES = \
evas-gl-drm: Rework gl_drm engine to function again Summary: Previous gl_drm evas engine code did not work properly (or at all really). This reworks/refactors the gl_drm engine code to work again with the changes made to ecore_drm. @fix Signed-off-by: Chris Michael <cp.michael@samsung.com>
2015-06-03 09:56:35 -07:00
modules/evas/engines/gl_drm/evas_outbuf.c \
evas: add evas gl-drm engine 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>
2014-08-21 02:22:16 -07:00
modules/evas/engines/gl_drm/evas_engine.c \
modules/evas/engines/gl_drm/evas_engine.h \
modules/evas/engines/gl_drm/Evas_Engine_GL_Drm.h
if EVAS_STATIC_BUILD_GL_DRM
lib_evas_libevas_la_SOURCES += $(GL_DRM_SOURCES)
lib_evas_libevas_la_CPPFLAGS += @evas_engine_gl_drm_cflags@
lib_evas_libevas_la_LIBADD += @evas_engine_gl_drm_libs@
else
enginegl_drmpkgdir = $(libdir)/evas/modules/engines/gl_drm/$(MODULE_ARCH)
enginegl_drmpkg_LTLIBRARIES = modules/evas/engines/gl_drm/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_enginegl_drmpkgLTLIBRARIES = install-enginegl_drmpkgLTLIBRARIES
$(install_enginegl_drmpkgLTLIBRARIES): install-libLTLIBRARIES
evas: add evas gl-drm engine 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>
2014-08-21 02:22:16 -07:00
modules_evas_engines_gl_drm_module_la_SOURCES = $(GL_DRM_SOURCES)
modules_evas_engines_gl_drm_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
-I$(top_srcdir)/src/lib/evas/include \
-I$(top_srcdir)/src/lib/evas/cserve2 \
-I$(top_srcdir)/src/modules/evas/engines/gl_drm \
@EVAS_CFLAGS@ \
evas-engines: Port evas drm engines to use Ecore_Drm2 library This patch ports the evas drm and gl_drm engines to use the new Ecore_Drm2 library Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
2016-05-03 09:02:20 -07:00
@ECORE_DRM2_CFLAGS@ \
evas: add evas gl-drm engine 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>
2014-08-21 02:22:16 -07:00
@evas_engine_gl_drm_cflags@
modules_evas_engines_gl_drm_module_la_LIBADD = \
@USE_EVAS_LIBS@ \
evas-engines: Port evas drm engines to use Ecore_Drm2 library This patch ports the evas drm and gl_drm engines to use the new Ecore_Drm2 library Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
2016-05-03 09:02:20 -07:00
@USE_ECORE_DRM2_LIBS@ \
evas: Fix improper extra library linkage for various engines The eglfs, drm and gl_drm engines were all linking to eeze internal libraries however none of those engines actually use eeze at all so we can remove the linking there. @fix Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
2016-04-26 07:02:35 -07:00
@evas_engine_gl_drm_libs@
evas-engines: Port evas drm engines to use Ecore_Drm2 library This patch ports the evas drm and gl_drm engines to use the new Ecore_Drm2 library Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
2016-05-03 09:02:20 -07:00
modules_evas_engines_gl_drm_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@ @USE_ECORE_DRM2_INTERNAL_LIBS@
evas: add evas gl-drm engine 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>
2014-08-21 02:22:16 -07:00
modules_evas_engines_gl_drm_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_engines_gl_drm_module_la_LIBTOOLFLAGS = --tag=disable-static
endif
endif
Add drm engine build infrastructure. Signed-off-by: Chris Michael <cp.michael@samsung.com>
2013-04-29 04:35:08 -07:00
evas: add eglfs evas module. 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>
2016-03-18 00:56:59 -07:00
if BUILD_ENGINE_EGLFS
EGLFS_SOURCES = \
modules/evas/engines/eglfs/evas_outbuf.c \
modules/evas/engines/eglfs/evas_engine.c \
modules/evas/engines/eglfs/evas_engine.h \
modules/evas/engines/eglfs/Evas_Engine_Eglfs.h
if EVAS_STATIC_BUILD_EGLFS
lib_evas_libevas_la_SOURCES += $(EGLFS_SOURCES)
lib_evas_libevas_la_CPPFLAGS += @evas_engine_eglfs_cflags@
lib_evas_libevas_la_LIBADD += @evas_engine_eglfs_libs@
else
engineeglfspkgdir = $(libdir)/evas/modules/engines/eglfs/$(MODULE_ARCH)
engineeglfspkg_LTLIBRARIES = modules/evas/engines/eglfs/module.la
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_engineeglfspkgLTLIBRARIES = install-engineeglfspkgLTLIBRARIES
$(install_engineeglfspkgLTLIBRARIES): install-libLTLIBRARIES
modules_evas_engines_eglfs_module_la_SOURCES = $(EGLFS_SOURCES)
modules_evas_engines_eglfs_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
-I$(top_srcdir)/src/lib/evas/include \
-I$(top_srcdir)/src/lib/evas/cserve2 \
-I$(top_srcdir)/src/modules/evas/engines/eglfs \
@EVAS_CFLAGS@ \
@ECORE_DRM_CFLAGS@ \
@evas_engine_eglfs_cflags@
modules_evas_engines_eglfs_module_la_LIBADD = \
@USE_EVAS_LIBS@ \
@USE_ECORE_DRM_LIBS@ \
evas: Fix improper extra library linkage for various engines The eglfs, drm and gl_drm engines were all linking to eeze internal libraries however none of those engines actually use eeze at all so we can remove the linking there. @fix Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
2016-04-26 07:02:35 -07:00
@evas_engine_eglfs_libs@
modules_evas_engines_eglfs_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@ @USE_ECORE_DRM_INTERNAL_LIBS@
evas: add eglfs evas module. 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>
2016-03-18 00:56:59 -07:00
modules_evas_engines_eglfs_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_engines_eglfs_module_la_LIBTOOLFLAGS = --tag=disable-static
endif
endif
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
### Cserve2 binary
if EVAS_CSERVE2
evascserve2internal_bindir=$(libdir)/evas/cserve2/bin/$(MODULE_ARCH)
evascserve2internal_bin_PROGRAMS = \
bin/evas/evas_cserve2 \
bin/evas/evas_cserve2_slave
noinst_PROGRAMS += \
bin/evas/dummy_slave
bin_PROGRAMS += \
bin/evas/evas_cserve2_client \
bin/evas/evas_cserve2_usage \
evas/cserve2: Add SHM debug tool (CLI) Prints out the content or the shared index. Does not need any socket connection to the server, read-only.
2013-08-21 18:43:53 -07:00
bin/evas/evas_cserve2_debug \
bin/evas/evas_cserve2_shm_debug
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
bin_evas_evas_cserve2_SOURCES = \
bin/evas/evas_cserve2.h \
bin/evas/evas_cserve2_slave.h \
bin/evas/evas_cserve2_main.c \
bin/evas/evas_cserve2_slaves.c \
bin/evas/evas_cserve2_messages.c \
bin/evas/evas_cserve2_shm.c \
bin/evas/evas_cserve2_cache.c \
bin/evas/evas_cserve2_requests.c \
bin/evas/evas_cserve2_fonts.c \
bin/evas/evas_cserve2_scale.c \
bin/evas/evas_cserve2_main_loop_linux.c \
evas/cserve2: Implement shared index and buffers Only import the C file for now. Implement the following features: - Shared Arrays Store arrays of elements of fixed size in shm. - Shared Mempool Store random sized buffers in shm. These buffers are indexed in a Shared Array and are referred to using their index only. - Shared Strings Store strings in a shm in a way similar to Eina_Stringshare (except strings are referred to using an int index). - Include evas_cserve2_index.c to the compilation. - Declare shared index functions in header file. - Call init() and shutdown() on the shared index subsystem. - Add find and foreach functions
2013-07-18 03:39:33 -07:00
bin/evas/evas_cserve2_index.c \
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
lib/evas/cserve2/evas_cs2_utils.h \
lib/evas/cserve2/evas_cs2_utils.c
bin_evas_evas_cserve2_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
evas/cserve2: use Evas_Image_Load_Opts directly Image_Data contained a similar struct to the standard Evas struct, let's not duplicate it uselessly.
2013-07-02 21:32:39 -07:00
-I$(top_srcdir)/src/lib/evas \
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
-I$(top_srcdir)/src/lib/evas/include \
-I$(top_srcdir)/src/lib/evas/cserve2 \
-DPACKAGE_BIN_DIR=\"$(bindir)\" \
-DPACKAGE_LIB_DIR=\"$(libdir)\" \
-DPACKAGE_DATA_DIR=\"$(datadir)/evas\" \
@EVAS_CFLAGS@
bin_evas_evas_cserve2_LDADD = @USE_EVAS_LIBS@
bin_evas_evas_cserve2_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
bin_evas_evas_cserve2_client_SOURCES = \
bin/evas/evas_cserve2_client.c
bin_evas_evas_cserve2_client_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
evas/cserve2: use Evas_Image_Load_Opts directly Image_Data contained a similar struct to the standard Evas struct, let's not duplicate it uselessly.
2013-07-02 21:32:39 -07:00
-I$(top_srcdir)/src/lib/evas \
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
-I$(top_srcdir)/src/lib/evas/cserve2 \
evas: use Emile to decode TGV.
2015-03-17 00:50:16 -07:00
@EVAS_CFLAGS@
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
bin_evas_evas_cserve2_client_LDADD = @USE_EINA_LIBS@
bin_evas_evas_cserve2_client_DEPENDENCIES = @USE_EINA_INTERNAL_LIBS@
bin_evas_evas_cserve2_usage_SOURCES = \
bin/evas/evas_cserve2_usage.c
bin_evas_evas_cserve2_usage_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
evas/cserve2: use Evas_Image_Load_Opts directly Image_Data contained a similar struct to the standard Evas struct, let's not duplicate it uselessly.
2013-07-02 21:32:39 -07:00
-I$(top_srcdir)/src/lib/evas \
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
-I$(top_srcdir)/src/lib/evas/cserve2 \
evas: use Emile to decode TGV.
2015-03-17 00:50:16 -07:00
@EVAS_CFLAGS@
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
bin_evas_evas_cserve2_usage_LDADD = @USE_EINA_LIBS@
bin_evas_evas_cserve2_usage_DEPENDENCIES = @USE_EINA_INTERNAL_LIBS@
bin_evas_evas_cserve2_debug_SOURCES = \
bin/evas/evas_cserve2_debug.c
bin_evas_evas_cserve2_debug_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
evas/cserve2: use Evas_Image_Load_Opts directly Image_Data contained a similar struct to the standard Evas struct, let's not duplicate it uselessly.
2013-07-02 21:32:39 -07:00
-I$(top_srcdir)/src/lib/evas \
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
-I$(top_srcdir)/src/lib/evas/cserve2 \
evas: use Emile to decode TGV.
2015-03-17 00:50:16 -07:00
@EVAS_CFLAGS@
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
bin_evas_evas_cserve2_debug_LDADD = @USE_EINA_LIBS@
bin_evas_evas_cserve2_debug_DEPENDENCIES = @USE_EINA_INTERNAL_LIBS@
evas/cserve2: Add SHM debug tool (CLI) Prints out the content or the shared index. Does not need any socket connection to the server, read-only.
2013-08-21 18:43:53 -07:00
bin_evas_evas_cserve2_shm_debug_SOURCES = \
bin/evas/evas_cserve2_shm_debug.c
bin_evas_evas_cserve2_shm_debug_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
-I$(top_srcdir)/src/lib/evas \
-I$(top_srcdir)/src/lib/evas/cserve2 \
evas: use Emile to decode TGV.
2015-03-17 00:50:16 -07:00
@EVAS_CFLAGS@
evas/cserve2: Add SHM debug tool (CLI) Prints out the content or the shared index. Does not need any socket connection to the server, read-only.
2013-08-21 18:43:53 -07:00
bin_evas_evas_cserve2_shm_debug_LDADD = @USE_EINA_LIBS@
bin_evas_evas_cserve2_shm_debug_DEPENDENCIES = @USE_EINA_INTERNAL_LIBS@
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
bin_evas_evas_cserve2_slave_SOURCES = \
bin/evas/evas_cserve2_slave.c \
bin/evas/evas_cserve2_utils.c \
$(lib_evas_file_SOURCES)
bin_evas_evas_cserve2_slave_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
evas/cserve2: use Evas_Image_Load_Opts directly Image_Data contained a similar struct to the standard Evas struct, let's not duplicate it uselessly.
2013-07-02 21:32:39 -07:00
-I$(top_srcdir)/src/lib/evas \
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
-I$(top_srcdir)/src/lib/evas/include \
-I$(top_srcdir)/src/lib/evas/cserve2 \
-DPACKAGE_BIN_DIR=\"$(bindir)\" \
-DPACKAGE_LIB_DIR=\"$(libdir)\" \
-DPACKAGE_DATA_DIR=\"$(datadir)/evas\" \
autotools: Fixed 'make examples' and 'make examples-install' It was broken in set-ups with ($(builddir) != $(srcdir)) && ($(builddir) != $(srcdir)/build)
2014-07-02 08:09:20 -07:00
-DPACKAGE_BUILD_DIR=\"$(abs_top_builddir)\" \
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
-DEVAS_MODULE_NO_ENGINES=1 \
-DEVAS_MODULE_NO_IMAGE_SAVERS=1 \
evas/module: Added a new module vg_loader for svg Reviewers: cedric, jpeg Subscribers: cedric, jpeg Differential Revision: https://phab.enlightenment.org/D4346
2016-10-12 02:39:10 -07:00
-DEVAS_MODULE_NO_VG_LOADERS=1 \
evas/module: add a new module in vg_saver for eet Reviewers: cedric, jpeg Subscribers: cedric, jpeg Differential Revision: https://phab.enlightenment.org/D4350
2016-10-13 23:52:51 -07:00
-DEVAS_MODULE_NO_VG_SAVERS=1 \
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
@EVAS_CFLAGS@
Evas: Fix build for cserve2 This should fix a strange build error for gentoo, reported by Branko. Dunno why it didn't fail with the default flags.
2015-04-06 21:49:48 -07:00
bin_evas_evas_cserve2_slave_LDADD = @EVAS_CSERVE2_SLAVE_LIBS@ @USE_EINA_LIBS@ @USE_EMILE_LIBS@
bin_evas_evas_cserve2_slave_DEPENDENCIES = @USE_EINA_INTERNAL_LIBS@ @USE_EO_INTERNAL_LIBS@ @USE_EMILE_INTERNAL_LIBS@
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
bin_evas_evas_cserve2_slave_LDFLAGS = -export-dynamic
bin_evas_dummy_slave_SOURCES = \
bin/evas/dummy_slave.c
bin_evas_dummy_slave_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
evas/cserve2: use Evas_Image_Load_Opts directly Image_Data contained a similar struct to the standard Evas struct, let's not duplicate it uselessly.
2013-07-02 21:32:39 -07:00
-I$(top_srcdir)/src/lib/evas \
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
-I$(top_srcdir)/src/lib/evas/include \
-I$(top_srcdir)/src/lib/evas/cserve2 \
@EVAS_CFLAGS@
Evas dummy_slave: Fix build race condition (failure to build). 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.
2014-08-21 05:19:09 -07:00
bin_evas_dummy_slave_DEPENDENCIES = @USE_EO_INTERNAL_LIBS@
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
bin_evas_dummy_slave_LDADD = \
@EVAS_LDFLAGS@ \
@EVAS_CSERVE2_SLAVE_LIBS@
endif
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
### loaders and savers
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
evas/module: Added a new module vg_loader for svg Reviewers: cedric, jpeg Subscribers: cedric, jpeg Differential Revision: https://phab.enlightenment.org/D4346
2016-10-12 02:39:10 -07:00
if BUILD_VG_LOADER_SVG
if EVAS_STATIC_BUILD_VG_SVG
vg_savers/svg: empty (for now) module that will save svg in original file Just as a starter to make a working background that, later on, will go through Svg_Node's and build a certain source code to be saved in SVG picture as a file
2017-01-27 03:54:47 -08:00
lib_evas_libevas_la_SOURCES += modules/evas/vg_loaders/svg/evas_vg_load_svg.c modules/evas/vg_savers/svg/evas_vg_save_svg.c \
static_lib: added vg_common static lib Features: Copied vg eet descriptor from edje_data Copied convert func from Svg_Node to Efl_VG from edje added convert function from Efl_VG to Svg_Node
2016-11-02 03:22:55 -07:00
static_libs/vg_common/vg_common.c \
Remove evas internal dependency from the evas_font module Summary: dev branch : devs/subhransu/font The Final goal is to move the evas_font module to ector so that both ector and evas can reuse the code. make the api simple so that sam eapi can be used by evas_textblock and ector text. This is the 1st stage to achive that gola, first remove the evas internal dependancy as much as possible before moving to ector library. Reviewers: jpeg, raster, herdsman, cedric, id213sin Subscribers: cedric, jpeg Differential Revision: https://phab.enlightenment.org/D5419
2017-11-06 18:22:09 -08:00
static_libs/vg_common/vg_common.h
static_lib: added vg_common static lib Features: Copied vg eet descriptor from edje_data Copied convert func from Svg_Node to Efl_VG from edje added convert function from Efl_VG to Svg_Node
2016-11-02 03:22:55 -07:00
lib_evas_libevas_la_CPPFLAGS += -I$(top_srcdir)/src/static_libs/vg_common \
@evas_vg_loader_svg_cflags@
evas/module: Added a new module vg_loader for svg Reviewers: cedric, jpeg Subscribers: cedric, jpeg Differential Revision: https://phab.enlightenment.org/D4346
2016-10-12 02:39:10 -07:00
lib_evas_libevas_la_LIBADD += @evas_vg_loader_svg_libs@
else
vgloadersvgpkgdir = $(libdir)/evas/modules/vg_loaders/svg/$(MODULE_ARCH)
vgloadersvgpkg_LTLIBRARIES = modules/evas/vg_loaders/svg/module.la
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_vgloadersvgpkgLTLIBRARIES = install-vgloadersvgpkgLTLIBRARIES
$(install_vgloadersvgpkgLTLIBRARIES): install-libLTLIBRARIES
static_lib: added vg_common static lib Features: Copied vg eet descriptor from edje_data Copied convert func from Svg_Node to Efl_VG from edje added convert function from Efl_VG to Svg_Node
2016-11-02 03:22:55 -07:00
modules_evas_vg_loaders_svg_module_la_SOURCES = modules/evas/vg_loaders/svg/evas_vg_load_svg.c \
static_libs/vg_common/vg_common.c \
static_libs/vg_common/vg_common.h
evas/module: Added a new module vg_loader for svg Reviewers: cedric, jpeg Subscribers: cedric, jpeg Differential Revision: https://phab.enlightenment.org/D4346
2016-10-12 02:39:10 -07:00
modules_evas_vg_loaders_svg_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
-I$(top_srcdir)/src/lib/evas/include \
static_lib: added vg_common static lib Features: Copied vg eet descriptor from edje_data Copied convert func from Svg_Node to Efl_VG from edje added convert function from Efl_VG to Svg_Node
2016-11-02 03:22:55 -07:00
-I$(top_srcdir)/src/static_libs/vg_common \
evas/module: Added a new module vg_loader for svg Reviewers: cedric, jpeg Subscribers: cedric, jpeg Differential Revision: https://phab.enlightenment.org/D4346
2016-10-12 02:39:10 -07:00
@EVAS_CFLAGS@ \
@evas_vg_loader_svg_cflags@
modules_evas_vg_loaders_svg_module_la_LIBADD = \
@USE_EVAS_LIBS@ \
@evas_vg_loader_svg_libs@
modules_evas_vg_loaders_svg_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_vg_loaders_svg_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_vg_loaders_svg_module_la_LIBTOOLFLAGS = --tag=disable-static
vg_savers/svg: empty (for now) module that will save svg in original file Just as a starter to make a working background that, later on, will go through Svg_Node's and build a certain source code to be saved in SVG picture as a file
2017-01-27 03:54:47 -08:00
vgsaversvgpkgdir = $(libdir)/evas/modules/vg_savers/svg/$(MODULE_ARCH)
vgsaversvgpkg_LTLIBRARIES = modules/evas/vg_savers/svg/module.la
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_vgsaversvgpkgLTLIBRARIES = install-vgloadersvgpkgLTLIBRARIES
$(install_vgsaversvgpkgLTLIBRARIES): install-libLTLIBRARIES
modules_evas_vg_savers_svg_module_la_SOURCES = modules/evas/vg_savers/svg/evas_vg_save_svg.c \
static_libs/vg_common/vg_common.c \
static_libs/vg_common/vg_common.h
modules_evas_vg_savers_svg_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
-I$(top_srcdir)/src/lib/evas/include \
-I$(top_srcdir)/src/static_libs/vg_common \
@EVAS_CFLAGS@ \
@evas_vg_saver_svg_cflags@
modules_evas_vg_savers_svg_module_la_LIBADD = \
@USE_EVAS_LIBS@ \
@evas_vg_saver_svg_libs@
modules_evas_vg_savers_svg_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_vg_savers_svg_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_vg_savers_svg_module_la_LIBTOOLFLAGS = --tag=disable-static
evas/module: Added a new module vg_loader for svg Reviewers: cedric, jpeg Subscribers: cedric, jpeg Differential Revision: https://phab.enlightenment.org/D4346
2016-10-12 02:39:10 -07:00
endif
endif
evas/module: add a new module in vg_loader for eet Reviewers: jpeg Subscribers: cedric, jpeg Differential Revision: https://phab.enlightenment.org/D4347
2016-10-13 01:09:39 -07:00
if BUILD_VG_LOADER_EET
if EVAS_STATIC_BUILD_VG_EET
evas/module: add a new module in vg_saver for eet Reviewers: cedric, jpeg Subscribers: cedric, jpeg Differential Revision: https://phab.enlightenment.org/D4350
2016-10-13 23:52:51 -07:00
lib_evas_libevas_la_SOURCES += modules/evas/vg_loaders/eet/evas_vg_load_eet.c modules/evas/vg_savers/eet/evas_vg_save_eet.c
evas/module: add a new module in vg_loader for eet Reviewers: jpeg Subscribers: cedric, jpeg Differential Revision: https://phab.enlightenment.org/D4347
2016-10-13 01:09:39 -07:00
lib_evas_libevas_la_CPPFLAGS += @evas_vg_loader_eet_cflags@
lib_evas_libevas_la_LIBADD += @evas_vg_loader_eet_libs@
else
vgloadereetpkgdir = $(libdir)/evas/modules/vg_loaders/eet/$(MODULE_ARCH)
vgloadereetpkg_LTLIBRARIES = modules/evas/vg_loaders/eet/module.la
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_vgloadereetpkgLTLIBRARIES = install-vgloadereetpkgLTLIBRARIES
$(install_vgloadereetpkgLTLIBRARIES): install-libLTLIBRARIES
modules_evas_vg_loaders_eet_module_la_SOURCES = modules/evas/vg_loaders/eet/evas_vg_load_eet.c
modules_evas_vg_loaders_eet_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
-I$(top_srcdir)/src/lib/evas/include \
@EVAS_CFLAGS@ \
@evas_vg_loader_eet_cflags@
modules_evas_vg_loaders_eet_module_la_LIBADD = \
@USE_EVAS_LIBS@ \
@evas_vg_loader_eet_libs@
modules_evas_vg_loaders_eet_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_vg_loaders_eet_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_vg_loaders_eet_module_la_LIBTOOLFLAGS = --tag=disable-static
evas/module: add a new module in vg_saver for eet Reviewers: cedric, jpeg Subscribers: cedric, jpeg Differential Revision: https://phab.enlightenment.org/D4350
2016-10-13 23:52:51 -07:00
vgsavereetpkgdir = $(libdir)/evas/modules/vg_savers/eet/$(MODULE_ARCH)
vgsavereetpkg_LTLIBRARIES = modules/evas/vg_savers/eet/module.la
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_vgsavereetpkgLTLIBRARIES = install-vgloadereetpkgLTLIBRARIES
$(install_vgsavereetpkgLTLIBRARIES): install-libLTLIBRARIES
modules_evas_vg_savers_eet_module_la_SOURCES = modules/evas/vg_savers/eet/evas_vg_save_eet.c
modules_evas_vg_savers_eet_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
-I$(top_srcdir)/src/lib/evas/include \
@EVAS_CFLAGS@ \
@evas_vg_saver_eet_cflags@
modules_evas_vg_savers_eet_module_la_LIBADD = \
@USE_EVAS_LIBS@ \
@evas_vg_saver_eet_libs@
modules_evas_vg_savers_eet_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_vg_savers_eet_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_vg_savers_eet_module_la_LIBTOOLFLAGS = --tag=disable-static
evas/module: add a new module in vg_loader for eet Reviewers: jpeg Subscribers: cedric, jpeg Differential Revision: https://phab.enlightenment.org/D4347
2016-10-13 01:09:39 -07:00
endif
endif
evas/module: Added a new module vg_loader for svg Reviewers: cedric, jpeg Subscribers: cedric, jpeg Differential Revision: https://phab.enlightenment.org/D4346
2016-10-12 02:39:10 -07:00
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
if BUILD_LOADER_BMP
if EVAS_STATIC_BUILD_BMP
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
lib_evas_libevas_la_SOURCES += modules/evas/image_loaders/bmp/evas_image_load_bmp.c
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib_evas_libevas_la_CPPFLAGS += @evas_image_loader_bmp_cflags@
lib_evas_libevas_la_LIBADD += @evas_image_loader_bmp_libs@
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
if EVAS_CSERVE2
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
bin_evas_evas_cserve2_slave_SOURCES += modules/evas/image_loaders/bmp/evas_image_load_bmp.c
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
bin_evas_evas_cserve2_slave_CPPFLAGS += @evas_image_loader_bmp_cflags@
bin_evas_evas_cserve2_slave_LDADD += @evas_image_loader_bmp_libs@
endif
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
else
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
loaderbmppkgdir = $(libdir)/evas/modules/image_loaders/bmp/$(MODULE_ARCH)
loaderbmppkg_LTLIBRARIES = modules/evas/image_loaders/bmp/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_loaderbmppkgLTLIBRARIES = install-loaderbmppkgLTLIBRARIES
$(install_loaderbmppkgLTLIBRARIES): install-libLTLIBRARIES
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_bmp_module_la_SOURCES = modules/evas/image_loaders/bmp/evas_image_load_bmp.c
modules_evas_image_loaders_bmp_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@EVAS_CFLAGS@ \
@evas_image_loader_bmp_cflags@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_bmp_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
efl: move -lm to configure.ac variables. EFL_ADD_LIBS() will add to requirements_libs_NAME and that will end into NAME_LIBS. SVN revision: 81910
2012-12-30 13:52:34 -08:00
@evas_image_loader_bmp_libs@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_bmp_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_image_loaders_bmp_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_image_loaders_bmp_module_la_LIBTOOLFLAGS = --tag=disable-static
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
endif
endif
Evas: Add DDS image file loader @feature: Add a Micrsoft DirectDraw Surface file loader
2014-06-18 01:55:44 -07:00
if BUILD_LOADER_DDS
if EVAS_STATIC_BUILD_DDS
Evas DDS: Implement DXT1 to RGBA decoding
2014-06-18 23:55:28 -07:00
lib_evas_libevas_la_SOURCES += \
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules/evas/image_loaders/dds/evas_image_load_dds.c \
modules/evas/image_loaders/dds/s3tc_decoder.c \
modules/evas/image_loaders/dds/s3tc.h
Evas: Add DDS image file loader @feature: Add a Micrsoft DirectDraw Surface file loader
2014-06-18 01:55:44 -07:00
lib_evas_libevas_la_CPPFLAGS += @evas_image_loader_dds_cflags@
lib_evas_libevas_la_LIBADD += @evas_image_loader_dds_libs@
if EVAS_CSERVE2
Evas DDS: Implement DXT1 to RGBA decoding
2014-06-18 23:55:28 -07:00
bin_evas_evas_cserve2_slave_SOURCES += \
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules/evas/image_loaders/dds/evas_image_load_dds.c \
modules/evas/image_loaders/dds/s3tc_decoder.c \
modules/evas/image_loaders/dds/s3tc.h
Evas: Add DDS image file loader @feature: Add a Micrsoft DirectDraw Surface file loader
2014-06-18 01:55:44 -07:00
bin_evas_evas_cserve2_slave_CPPFLAGS += @evas_image_loader_dds_cflags@
bin_evas_evas_cserve2_slave_LDADD += @evas_image_loader_dds_libs@
endif
else
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
loaderddspkgdir = $(libdir)/evas/modules/image_loaders/dds/$(MODULE_ARCH)
loaderddspkg_LTLIBRARIES = modules/evas/image_loaders/dds/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_loaderddspkgLTLIBRARIES = install-loaderddspkgLTLIBRARIES
$(install_loaderddspkgLTLIBRARIES): install-libLTLIBRARIES
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_dds_module_la_SOURCES = \
modules/evas/image_loaders/dds/evas_image_load_dds.c \
modules/evas/image_loaders/dds/s3tc_decoder.c \
modules/evas/image_loaders/dds/s3tc.h
modules_evas_image_loaders_dds_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
Evas: Add DDS image file loader @feature: Add a Micrsoft DirectDraw Surface file loader
2014-06-18 01:55:44 -07:00
-I$(top_srcdir)/src/lib/evas/include \
@EVAS_CFLAGS@ \
@evas_image_loader_dds_cflags@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_dds_module_la_LIBADD = \
Evas: Add DDS image file loader @feature: Add a Micrsoft DirectDraw Surface file loader
2014-06-18 01:55:44 -07:00
@USE_EVAS_LIBS@ \
@evas_image_loader_dds_libs@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_dds_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_image_loaders_dds_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_image_loaders_dds_module_la_LIBTOOLFLAGS = --tag=disable-static
Evas: Add DDS image file loader @feature: Add a Micrsoft DirectDraw Surface file loader
2014-06-18 01:55:44 -07:00
endif
endif
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
if BUILD_LOADER_EET
if EVAS_STATIC_BUILD_EET
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
lib_evas_libevas_la_SOURCES += modules/evas/image_loaders/eet/evas_image_load_eet.c modules/evas/image_savers/eet/evas_image_save_eet.c
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib_evas_libevas_la_CPPFLAGS += @evas_image_loader_eet_cflags@
lib_evas_libevas_la_LIBADD += @evas_image_loader_eet_libs@
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
if EVAS_CSERVE2
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
bin_evas_evas_cserve2_slave_SOURCES += modules/evas/image_loaders/eet/evas_image_load_eet.c
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
bin_evas_evas_cserve2_slave_CPPFLAGS += @evas_image_loader_eet_cflags@
evas: fix build Build may fail when using parallel compilation (-j) Add EET as a dependency of cserve slave
2013-07-02 02:54:57 -07:00
bin_evas_evas_cserve2_slave_DEPENDENCIES += @USE_EET_INTERNAL_LIBS@
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
bin_evas_evas_cserve2_slave_LDADD += @USE_EET_LIBS@ @evas_image_loader_eet_libs@
endif
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
else
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
loadereetpkgdir = $(libdir)/evas/modules/image_loaders/eet/$(MODULE_ARCH)
loadereetpkg_LTLIBRARIES = modules/evas/image_loaders/eet/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_loadereetpkgLTLIBRARIES = install-loadereetpkgLTLIBRARIES
$(install_loadereetpkgLTLIBRARIES): install-libLTLIBRARIES
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_eet_module_la_SOURCES = modules/evas/image_loaders/eet/evas_image_load_eet.c
modules_evas_image_loaders_eet_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@EVAS_CFLAGS@ \
@evas_image_loader_eet_cflags@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_eet_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@evas_image_loader_eet_libs@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_eet_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_image_loaders_eet_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_image_loaders_eet_module_la_LIBTOOLFLAGS = --tag=disable-static
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
endif
endif
if BUILD_LOADER_GENERIC
if EVAS_STATIC_BUILD_GENERIC
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
lib_evas_libevas_la_SOURCES += modules/evas/image_loaders/generic/evas_image_load_generic.c
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib_evas_libevas_la_CPPFLAGS += @evas_image_loader_generic_cflags@
lib_evas_libevas_la_LIBADD += @evas_image_loader_generic_libs@
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
if EVAS_CSERVE2
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
bin_evas_evas_cserve2_slave_SOURCES += modules/evas/image_loaders/generic/evas_image_load_generic.c
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
bin_evas_evas_cserve2_slave_CPPFLAGS += @evas_image_loader_generic_cflags@
bin_evas_evas_cserve2_slave_LDADD += @evas_image_loader_generic_libs@
endif
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
else
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
loadergenericpkgdir = $(libdir)/evas/modules/image_loaders/generic/$(MODULE_ARCH)
loadergenericpkg_LTLIBRARIES = modules/evas/image_loaders/generic/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_loadergenericpkgLTLIBRARIES = install-loadergenericpkgLTLIBRARIES
$(install_loadergenericpkgLTLIBRARIES): install-libLTLIBRARIES
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_generic_module_la_SOURCES = modules/evas/image_loaders/generic/evas_image_load_generic.c
modules_evas_image_loaders_generic_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@EVAS_CFLAGS@ \
@evas_image_loader_generic_cflags@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_generic_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@evas_image_loader_generic_libs@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_generic_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_image_loaders_generic_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_image_loaders_generic_module_la_LIBTOOLFLAGS = --tag=disable-static
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
endif
endif
if BUILD_LOADER_GIF
if EVAS_STATIC_BUILD_GIF
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
lib_evas_libevas_la_SOURCES += modules/evas/image_loaders/gif/evas_image_load_gif.c
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib_evas_libevas_la_CPPFLAGS += @evas_image_loader_gif_cflags@
lib_evas_libevas_la_LIBADD += @evas_image_loader_gif_libs@
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
if EVAS_CSERVE2
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
bin_evas_evas_cserve2_slave_SOURCES += modules/evas/image_loaders/gif/evas_image_load_gif.c
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
bin_evas_evas_cserve2_slave_CPPFLAGS += @evas_image_loader_gif_cflags@
bin_evas_evas_cserve2_slave_LDADD += @evas_image_loader_gif_libs@
endif
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
else
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
loadergifpkgdir = $(libdir)/evas/modules/image_loaders/gif/$(MODULE_ARCH)
loadergifpkg_LTLIBRARIES = modules/evas/image_loaders/gif/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_loadergifpkgLTLIBRARIES = install-loadergifpkgLTLIBRARIES
$(install_loadergifpkgLTLIBRARIES): install-libLTLIBRARIES
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_gif_module_la_SOURCES = modules/evas/image_loaders/gif/evas_image_load_gif.c
modules_evas_image_loaders_gif_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@EVAS_CFLAGS@ \
@evas_image_loader_gif_cflags@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_gif_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@evas_image_loader_gif_libs@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_gif_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_image_loaders_gif_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_image_loaders_gif_module_la_LIBTOOLFLAGS = --tag=disable-static
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
endif
endif
if BUILD_LOADER_ICO
if EVAS_STATIC_BUILD_ICO
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
lib_evas_libevas_la_SOURCES += modules/evas/image_loaders/ico/evas_image_load_ico.c
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib_evas_libevas_la_CPPFLAGS += @evas_image_loader_ico_cflags@
lib_evas_libevas_la_LIBADD += @evas_image_loader_ico_libs@
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
if EVAS_CSERVE2
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
bin_evas_evas_cserve2_slave_SOURCES += modules/evas/image_loaders/ico/evas_image_load_ico.c
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
bin_evas_evas_cserve2_slave_CPPFLAGS += @evas_image_loader_ico_cflags@
bin_evas_evas_cserve2_slave_LDADD += @evas_image_loader_ico_libs@
endif
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
else
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
loadericopkgdir = $(libdir)/evas/modules/image_loaders/ico/$(MODULE_ARCH)
loadericopkg_LTLIBRARIES = modules/evas/image_loaders/ico/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_loadericopkgLTLIBRARIES = install-loadericopkgLTLIBRARIES
$(install_loadericopkgLTLIBRARIES): install-libLTLIBRARIES
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_ico_module_la_SOURCES = modules/evas/image_loaders/ico/evas_image_load_ico.c
modules_evas_image_loaders_ico_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@EVAS_CFLAGS@ \
@evas_image_loader_ico_cflags@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_ico_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@evas_image_loader_ico_libs@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_ico_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_image_loaders_ico_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_image_loaders_ico_module_la_LIBTOOLFLAGS = --tag=disable-static
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
endif
endif
if BUILD_LOADER_JPEG
if EVAS_STATIC_BUILD_JPEG
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
lib_evas_libevas_la_SOURCES += modules/evas/image_loaders/jpeg/evas_image_load_jpeg.c
lib_evas_libevas_la_SOURCES += modules/evas/image_savers/jpeg/evas_image_save_jpeg.c
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib_evas_libevas_la_CPPFLAGS += @evas_image_loader_jpeg_cflags@
lib_evas_libevas_la_LIBADD += @evas_image_loader_jpeg_libs@
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
if EVAS_CSERVE2
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
bin_evas_evas_cserve2_slave_SOURCES += modules/evas/image_loaders/jpeg/evas_image_load_jpeg.c
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
bin_evas_evas_cserve2_slave_CPPFLAGS += @evas_image_loader_jpeg_cflags@
bin_evas_evas_cserve2_slave_LDADD += @evas_image_loader_jpeg_libs@
endif
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
else
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
loaderjpegpkgdir = $(libdir)/evas/modules/image_loaders/jpeg/$(MODULE_ARCH)
loaderjpegpkg_LTLIBRARIES = modules/evas/image_loaders/jpeg/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_loaderjpegpkgLTLIBRARIES = install-loaderjpegpkgLTLIBRARIES
$(install_loaderjpegpkgLTLIBRARIES): install-libLTLIBRARIES
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_jpeg_module_la_SOURCES = modules/evas/image_loaders/jpeg/evas_image_load_jpeg.c
modules_evas_image_loaders_jpeg_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@EVAS_CFLAGS@ \
@evas_image_loader_jpeg_cflags@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_jpeg_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@evas_image_loader_jpeg_libs@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_jpeg_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_image_loaders_jpeg_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_image_loaders_jpeg_module_la_LIBTOOLFLAGS = --tag=disable-static
saverjpegpkgdir = $(libdir)/evas/modules/image_savers/jpeg/$(MODULE_ARCH)
saverjpegpkg_LTLIBRARIES = modules/evas/image_savers/jpeg/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_saverjpegpkgLTLIBRARIES = install-saverjpegpkgLTLIBRARIES
$(install_saverjpegpkgLTLIBRARIES): install-libLTLIBRARIES
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_savers_jpeg_module_la_SOURCES = modules/evas/image_savers/jpeg/evas_image_save_jpeg.c
modules_evas_image_savers_jpeg_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@EVAS_CFLAGS@ \
@evas_image_loader_jpeg_cflags@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_savers_jpeg_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@evas_image_loader_jpeg_libs@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_savers_jpeg_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_image_savers_jpeg_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_image_savers_jpeg_module_la_LIBTOOLFLAGS = --tag=disable-static
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
endif
endif
evas: add JPEG 2000 loader. 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.
2013-09-28 05:28:41 -07:00
if BUILD_LOADER_JP2K
if EVAS_STATIC_BUILD_JP2K
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
lib_evas_libevas_la_SOURCES += modules/evas/image_loaders/jp2k/evas_image_load_jp2k.c
evas: add JPEG 2000 loader. 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.
2013-09-28 05:28:41 -07:00
lib_evas_libevas_la_CPPFLAGS += @evas_image_loader_jp2k_cflags@
lib_evas_libevas_la_LIBADD += @evas_image_loader_jp2k_libs@
if EVAS_CSERVE2
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
bin_evas_evas_cserve2_slave_SOURCES += modules/evas/image_loaders/jp2k/evas_image_load_jp2k.c
evas: add JPEG 2000 loader. 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.
2013-09-28 05:28:41 -07:00
bin_evas_evas_cserve2_slave_CPPFLAGS += @evas_image_loader_jp2k_cflags@
bin_evas_evas_cserve2_slave_LDADD += @evas_image_loader_jp2k_libs@
endif
else
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
loaderjp2kpkgdir = $(libdir)/evas/modules/image_loaders/jp2k/$(MODULE_ARCH)
loaderjp2kpkg_LTLIBRARIES = modules/evas/image_loaders/jp2k/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_loaderjp2kpkgLTLIBRARIES = install-loaderjp2kpkgLTLIBRARIES
$(install_loaderjp2kpkgLTLIBRARIES): install-libLTLIBRARIES
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_jp2k_module_la_SOURCES = modules/evas/image_loaders/jp2k/evas_image_load_jp2k.c
makefile_evas: fix includes when openjpeg 1.5 and 2.0 are installed. Reviewers: vtorri Subscribers: ManMower, cedric, jpeg Differential Revision: https://phab.enlightenment.org/D5084
2017-08-11 11:10:10 -07:00
modules_evas_image_loaders_jp2k_module_la_CPPFLAGS = \
@evas_image_loader_jp2k_cflags@ \
-I$(top_builddir)/src/lib/efl \
evas: add JPEG 2000 loader. 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.
2013-09-28 05:28:41 -07:00
-I$(top_srcdir)/src/lib/evas/include \
makefile_evas: fix includes when openjpeg 1.5 and 2.0 are installed. Reviewers: vtorri Subscribers: ManMower, cedric, jpeg Differential Revision: https://phab.enlightenment.org/D5084
2017-08-11 11:10:10 -07:00
@EVAS_CFLAGS@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_jp2k_module_la_LIBADD = \
evas: add JPEG 2000 loader. 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.
2013-09-28 05:28:41 -07:00
@USE_EVAS_LIBS@ \
@evas_image_loader_jp2k_libs@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_jp2k_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_image_loaders_jp2k_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_image_loaders_jp2k_module_la_LIBTOOLFLAGS = --tag=disable-static
evas: add JPEG 2000 loader. 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.
2013-09-28 05:28:41 -07:00
endif
endif
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
if BUILD_LOADER_PMAPS
if EVAS_STATIC_BUILD_PMAPS
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
lib_evas_libevas_la_SOURCES += modules/evas/image_loaders/pmaps/evas_image_load_pmaps.c
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib_evas_libevas_la_CPPFLAGS += @evas_image_loader_pmaps_cflags@
lib_evas_libevas_la_LIBADD += @evas_image_loader_pmaps_libs@
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
if EVAS_CSERVE2
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
bin_evas_evas_cserve2_slave_SOURCES += modules/evas/image_loaders/pmaps/evas_image_load_pmaps.c
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
bin_evas_evas_cserve2_slave_CPPFLAGS += @evas_image_loader_pmaps_cflags@
bin_evas_evas_cserve2_slave_LDADD += @evas_image_loader_pmaps_libs@
endif
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
else
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
loaderpmapspkgdir = $(libdir)/evas/modules/image_loaders/pmaps/$(MODULE_ARCH)
loaderpmapspkg_LTLIBRARIES = modules/evas/image_loaders/pmaps/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_loaderpmapspkgLTLIBRARIES = install-loaderpmapspkgLTLIBRARIES
$(install_loaderpmapspkgLTLIBRARIES): install-libLTLIBRARIES
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_pmaps_module_la_SOURCES = modules/evas/image_loaders/pmaps/evas_image_load_pmaps.c
modules_evas_image_loaders_pmaps_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@EVAS_CFLAGS@ \
@evas_image_loader_pmaps_cflags@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_pmaps_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@evas_image_loader_pmaps_libs@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_pmaps_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_image_loaders_pmaps_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_image_loaders_pmaps_module_la_LIBTOOLFLAGS = --tag=disable-static
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
endif
endif
if BUILD_LOADER_PNG
if EVAS_STATIC_BUILD_PNG
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
lib_evas_libevas_la_SOURCES += modules/evas/image_loaders/png/evas_image_load_png.c modules/evas/image_savers/png/evas_image_save_png.c
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib_evas_libevas_la_CPPFLAGS += @evas_image_loader_png_cflags@
lib_evas_libevas_la_LIBADD += @evas_image_loader_png_libs@
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
if EVAS_CSERVE2
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
bin_evas_evas_cserve2_slave_SOURCES += modules/evas/image_loaders/png/evas_image_load_png.c
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
bin_evas_evas_cserve2_slave_CPPFLAGS += @evas_image_loader_png_cflags@
evas: fix build when png12 is not around.
2013-07-02 18:09:31 -07:00
bin_evas_evas_cserve2_slave_LDADD += @evas_image_loader_png_libs@
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
endif
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
else
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
loaderpngpkgdir = $(libdir)/evas/modules/image_loaders/png/$(MODULE_ARCH)
loaderpngpkg_LTLIBRARIES = modules/evas/image_loaders/png/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_loaderpngpkgLTLIBRARIES = install-loaderpngpkgLTLIBRARIES
$(install_loaderpngpkgLTLIBRARIES): install-libLTLIBRARIES
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_png_module_la_SOURCES = modules/evas/image_loaders/png/evas_image_load_png.c
modules_evas_image_loaders_png_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@EVAS_CFLAGS@ \
@evas_image_loader_png_cflags@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_png_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@evas_image_loader_png_libs@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_png_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_image_loaders_png_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_image_loaders_png_module_la_LIBTOOLFLAGS = --tag=disable-static
saverpngpkgdir = $(libdir)/evas/modules/image_savers/png/$(MODULE_ARCH)
saverpngpkg_LTLIBRARIES = modules/evas/image_savers/png/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_saverpngpkgLTLIBRARIES = install-saverpngpkgLTLIBRARIES
$(install_saverpngpkgLTLIBRARIES): install-libLTLIBRARIES
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_savers_png_module_la_SOURCES = modules/evas/image_savers/png/evas_image_save_png.c
modules_evas_image_savers_png_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@EVAS_CFLAGS@ \
@evas_image_loader_png_cflags@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_savers_png_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@evas_image_loader_png_libs@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_savers_png_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_image_savers_png_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_image_savers_png_module_la_LIBTOOLFLAGS = --tag=disable-static
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
endif
endif
if BUILD_LOADER_PSD
if EVAS_STATIC_BUILD_PSD
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
lib_evas_libevas_la_SOURCES += modules/evas/image_loaders/psd/evas_image_load_psd.c
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib_evas_libevas_la_CPPFLAGS += @evas_image_loader_psd_cflags@
lib_evas_libevas_la_LIBADD += @evas_image_loader_psd_libs@
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
if EVAS_CSERVE2
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
bin_evas_evas_cserve2_slave_SOURCES += modules/evas/image_loaders/psd/evas_image_load_psd.c
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
bin_evas_evas_cserve2_slave_CPPFLAGS += @evas_image_loader_psd_cflags@
bin_evas_evas_cserve2_slave_LDADD += @evas_image_loader_psd_libs@
endif
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
else
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
loaderpsdpkgdir = $(libdir)/evas/modules/image_loaders/psd/$(MODULE_ARCH)
loaderpsdpkg_LTLIBRARIES = modules/evas/image_loaders/psd/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_loaderpsdpkgLTLIBRARIES = install-loaderpsdpkgLTLIBRARIES
$(install_loaderpsdpkgLTLIBRARIES): install-libLTLIBRARIES
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_psd_module_la_SOURCES = modules/evas/image_loaders/psd/evas_image_load_psd.c
modules_evas_image_loaders_psd_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@EVAS_CFLAGS@ \
@evas_image_loader_psd_cflags@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_psd_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@evas_image_loader_psd_libs@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_psd_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_image_loaders_psd_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_image_loaders_psd_module_la_LIBTOOLFLAGS = --tag=disable-static
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
endif
endif
if BUILD_LOADER_TGA
if EVAS_STATIC_BUILD_TGA
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
lib_evas_libevas_la_SOURCES += modules/evas/image_loaders/tga/evas_image_load_tga.c
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib_evas_libevas_la_CPPFLAGS += @evas_image_loader_tga_cflags@
lib_evas_libevas_la_LIBADD += @evas_image_loader_tga_libs@
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
if EVAS_CSERVE2
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
bin_evas_evas_cserve2_slave_SOURCES += modules/evas/image_loaders/tga/evas_image_load_tga.c
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
bin_evas_evas_cserve2_slave_CPPFLAGS += @evas_image_loader_tga_cflags@
bin_evas_evas_cserve2_slave_LDADD += @evas_image_loader_tga_libs@
endif
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
else
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
loadertgapkgdir = $(libdir)/evas/modules/image_loaders/tga/$(MODULE_ARCH)
loadertgapkg_LTLIBRARIES = modules/evas/image_loaders/tga/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_loadertgapkgLTLIBRARIES = install-loadertgapkgLTLIBRARIES
$(install_loadertgapkgLTLIBRARIES): install-libLTLIBRARIES
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_tga_module_la_SOURCES = modules/evas/image_loaders/tga/evas_image_load_tga.c
modules_evas_image_loaders_tga_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@EVAS_CFLAGS@ \
@evas_image_loader_tga_cflags@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_tga_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@evas_image_loader_tga_libs@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_tga_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_image_loaders_tga_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_image_loaders_tga_module_la_LIBTOOLFLAGS = --tag=disable-static
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
endif
endif
if BUILD_LOADER_TIFF
if EVAS_STATIC_BUILD_TIFF
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
lib_evas_libevas_la_SOURCES += modules/evas/image_loaders/tiff/evas_image_load_tiff.c modules/evas/image_savers/tiff/evas_image_save_tiff.c
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib_evas_libevas_la_CPPFLAGS += @evas_image_loader_tiff_cflags@
lib_evas_libevas_la_LIBADD += @evas_image_loader_tiff_libs@
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
if EVAS_CSERVE2
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
bin_evas_evas_cserve2_slave_SOURCES += modules/evas/image_loaders/tiff/evas_image_load_tiff.c
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
bin_evas_evas_cserve2_slave_CPPFLAGS += @evas_image_loader_tiff_cflags@
bin_evas_evas_cserve2_slave_LDADD += @evas_image_loader_tiff_libs@
endif
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
else
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
loadertiffpkgdir = $(libdir)/evas/modules/image_loaders/tiff/$(MODULE_ARCH)
loadertiffpkg_LTLIBRARIES = modules/evas/image_loaders/tiff/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_loadertiffpkgLTLIBRARIES = install-loadertiffpkgLTLIBRARIES
$(install_loadertiffpkgLTLIBRARIES): install-libLTLIBRARIES
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_tiff_module_la_SOURCES = modules/evas/image_loaders/tiff/evas_image_load_tiff.c
modules_evas_image_loaders_tiff_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
efl: simplify linkage/usage of evil on windows. instead of spreading it all around, just define 2 AC_SUBST() that will do the work. SVN revision: 81477
2012-12-20 11:25:51 -08:00
@EVAS_CFLAGS@ \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@evas_image_loader_tiff_cflags@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_tiff_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@evas_image_loader_tiff_libs@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_tiff_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_image_loaders_tiff_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_image_loaders_tiff_module_la_LIBTOOLFLAGS = --tag=disable-static
savertiffpkgdir = $(libdir)/evas/modules/image_savers/tiff/$(MODULE_ARCH)
savertiffpkg_LTLIBRARIES = modules/evas/image_savers/tiff/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_savertiffpkgLTLIBRARIES = install-savertiffpkgLTLIBRARIES
$(install_savertiffpkgLTLIBRARIES): install-libLTLIBRARIES
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_savers_tiff_module_la_SOURCES = modules/evas/image_savers/tiff/evas_image_save_tiff.c
modules_evas_image_savers_tiff_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
efl: simplify linkage/usage of evil on windows. instead of spreading it all around, just define 2 AC_SUBST() that will do the work. SVN revision: 81477
2012-12-20 11:25:51 -08:00
@EVAS_CFLAGS@ \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@evas_image_loader_tiff_cflags@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_savers_tiff_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@evas_image_loader_tiff_libs@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_savers_tiff_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_image_savers_tiff_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_image_savers_tiff_module_la_LIBTOOLFLAGS = --tag=disable-static
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
endif
endif
if BUILD_LOADER_WBMP
if EVAS_STATIC_BUILD_WBMP
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
lib_evas_libevas_la_SOURCES += modules/evas/image_loaders/wbmp/evas_image_load_wbmp.c
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib_evas_libevas_la_CPPFLAGS += @evas_image_loader_wbmp_cflags@
lib_evas_libevas_la_LIBADD += @evas_image_loader_wbmp_libs@
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
if EVAS_CSERVE2
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
bin_evas_evas_cserve2_slave_SOURCES += modules/evas/image_loaders/wbmp/evas_image_load_wbmp.c
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
bin_evas_evas_cserve2_slave_CPPFLAGS += @evas_image_loader_wbmp_cflags@
bin_evas_evas_cserve2_slave_LDADD += @evas_image_loader_wbmp_libs@
endif
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
else
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
loaderwbmppkgdir = $(libdir)/evas/modules/image_loaders/wbmp/$(MODULE_ARCH)
loaderwbmppkg_LTLIBRARIES = modules/evas/image_loaders/wbmp/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_loaderwbmppkgLTLIBRARIES = install-loaderwbmppkgLTLIBRARIES
$(install_loaderwbmppkgLTLIBRARIES): install-libLTLIBRARIES
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_wbmp_module_la_SOURCES = modules/evas/image_loaders/wbmp/evas_image_load_wbmp.c
modules_evas_image_loaders_wbmp_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@EVAS_CFLAGS@ \
@evas_image_loader_wbmp_cflags@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_wbmp_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@evas_image_loader_wbmp_libs@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_wbmp_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_image_loaders_wbmp_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_image_loaders_wbmp_module_la_LIBTOOLFLAGS = --tag=disable-static
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
endif
endif
if BUILD_LOADER_WEBP
if EVAS_STATIC_BUILD_WEBP
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
lib_evas_libevas_la_SOURCES += modules/evas/image_loaders/webp/evas_image_load_webp.c modules/evas/image_savers/webp/evas_image_save_webp.c
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib_evas_libevas_la_CPPFLAGS += @evas_image_loader_webp_cflags@
lib_evas_libevas_la_LIBADD += @evas_image_loader_webp_libs@
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
if EVAS_CSERVE2
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
bin_evas_evas_cserve2_slave_SOURCES += modules/evas/image_loaders/webp/evas_image_load_webp.c
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
bin_evas_evas_cserve2_slave_CPPFLAGS += @evas_image_loader_webp_cflags@
bin_evas_evas_cserve2_slave_LDADD += @evas_image_loader_webp_libs@
endif
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
else
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
loaderwebppkgdir = $(libdir)/evas/modules/image_loaders/webp/$(MODULE_ARCH)
loaderwebppkg_LTLIBRARIES = modules/evas/image_loaders/webp/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_loaderwebppkgLTLIBRARIES = install-loaderwebppkgLTLIBRARIES
$(install_loaderwebppkgLTLIBRARIES): install-libLTLIBRARIES
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_webp_module_la_SOURCES = modules/evas/image_loaders/webp/evas_image_load_webp.c
modules_evas_image_loaders_webp_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@EVAS_CFLAGS@ \
@evas_image_loader_webp_cflags@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_webp_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@evas_image_loader_webp_libs@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_webp_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_image_loaders_webp_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_image_loaders_webp_module_la_LIBTOOLFLAGS = --tag=disable-static
saverwebppkgdir = $(libdir)/evas/modules/image_savers/webp/$(MODULE_ARCH)
saverwebppkg_LTLIBRARIES = modules/evas/image_savers/webp/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_saverwebppkgLTLIBRARIES = install-saverwebppkgLTLIBRARIES
$(install_saverwebppkgLTLIBRARIES): install-libLTLIBRARIES
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_savers_webp_module_la_SOURCES = modules/evas/image_savers/webp/evas_image_save_webp.c
modules_evas_image_savers_webp_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
evas: Add WebP image saver
2013-03-05 15:09:05 -08:00
-I$(top_srcdir)/src/lib/evas/include \
@EVAS_CFLAGS@ \
@evas_image_loader_webp_cflags@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_savers_webp_module_la_LIBADD = \
evas: Add WebP image saver
2013-03-05 15:09:05 -08:00
@USE_EVAS_LIBS@ \
@evas_image_loader_webp_libs@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_savers_webp_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_image_savers_webp_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_image_savers_webp_module_la_LIBTOOLFLAGS = --tag=disable-static
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
endif
endif
if BUILD_LOADER_XPM
if EVAS_STATIC_BUILD_XPM
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
lib_evas_libevas_la_SOURCES += modules/evas/image_loaders/xpm/evas_image_load_xpm.c
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
lib_evas_libevas_la_CPPFLAGS += @evas_image_loader_xpm_cflags@
lib_evas_libevas_la_LIBADD += @evas_image_loader_xpm_libs@
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
if EVAS_CSERVE2
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
bin_evas_evas_cserve2_slave_SOURCES += modules/evas/image_loaders/xpm/evas_image_load_xpm.c
evas: build evas_module within cserve slave Objective: use common loaders from cserve2 Ideally evas_module should be a static library but it would then require static/dynamic linking to too many modules unused by cserve2 (eg. engines & savers) Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
2013-06-26 23:31:20 -07:00
bin_evas_evas_cserve2_slave_CPPFLAGS += @evas_image_loader_xpm_cflags@
bin_evas_evas_cserve2_slave_LDADD += @evas_image_loader_xpm_libs@
endif
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
else
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
loaderxpmpkgdir = $(libdir)/evas/modules/image_loaders/xpm/$(MODULE_ARCH)
loaderxpmpkg_LTLIBRARIES = modules/evas/image_loaders/xpm/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_loaderxpmpkgLTLIBRARIES = install-loaderxpmpkgLTLIBRARIES
$(install_loaderxpmpkgLTLIBRARIES): install-libLTLIBRARIES
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_xpm_module_la_SOURCES = modules/evas/image_loaders/xpm/evas_image_load_xpm.c
modules_evas_image_loaders_xpm_module_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
-I$(top_srcdir)/src/lib/evas/include \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@EVAS_CFLAGS@ \
@evas_image_loader_xpm_cflags@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_xpm_module_la_LIBADD = \
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
@USE_EVAS_LIBS@ \
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
@evas_image_loader_xpm_libs@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_xpm_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_image_loaders_xpm_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_image_loaders_xpm_module_la_LIBTOOLFLAGS = --tag=disable-static
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
endif
endif
evas: add a tgv loader. The TGV file format is specifically created for Evas. It is designed to allow region decompression and parallele decompression with a fast path for GPU that do handle ETC1 compression. Plan for adding other compression method will come later.
2014-03-11 03:08:40 -07:00
if BUILD_LOADER_TGV
build: split EXTRA_DIST files in src/ off from DISTFILES and handle separately This is again to avoid the "Argument list too long" error we are hitting more and more now. Given we just merged elementary, emotion generic players, evas generic loaders and elm_code it is not surprising we are hitting it again. This time the number of files being hold in DISTFILES has just grown to big so a make dist was no longer possible. If one looks at what the DISTFILES variable from automake holds you can image it grows a lot with all the source files plus generated files we have in tree now. DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) To cut off a big chunk but still keep all the other automagic in place for SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle the files in a dist-hook now. Another thing to note here is that this also only happens as we have the one big Makefile with includes. If we go back to per directory Makefiles this problem should vanish as well. In any case we need a solution for 1.18 now and this is what I have to offer. If you have a cleaner solution in mind feel welcome to test it out and if everything we need keeps working (make, make examples, make check, make benchmark, make dist and make distcheck) go ahead.
2016-06-08 01:26:06 -07:00
EXTRA_DIST2 += static_libs/rg_etc/README
evas: add a tgv loader. The TGV file format is specifically created for Evas. It is designed to allow region decompression and parallele decompression with a fast path for GPU that do handle ETC1 compression. Plan for adding other compression method will come later.
2014-03-11 03:08:40 -07:00
if EVAS_STATIC_BUILD_TGV
lib_evas_libevas_la_SOURCES += \
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules/evas/image_loaders/tgv/evas_image_load_tgv.c \
evas: etc code is now always needed for the color conversion logic.
2016-04-18 14:41:47 -07:00
modules/evas/image_savers/tgv/evas_image_save_tgv.c
build: Allow to use external liblz4 instead of embedded copy 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>
2014-08-12 00:37:33 -07:00
if ! ENABLE_LIBLZ4
lib_evas_libevas_la_SOURCES += \
evas: add a tgv loader. The TGV file format is specifically created for Evas. It is designed to allow region decompression and parallele decompression with a fast path for GPU that do handle ETC1 compression. Plan for adding other compression method will come later.
2014-03-11 03:08:40 -07:00
static_libs/lz4/lz4.c \
Evas ETC1: Use LZ4HC for higher compression ratios LZ4HC has a higher compression ratio than LZ4 but basically the same decompression speed. The performance cost during encoding is actually still pretty low considering how expensive ETC1 compression can be (even at medium quality).
2014-04-14 19:41:16 -07:00
static_libs/lz4/lz4.h \
static_libs/lz4/lz4hc.c \
static_libs/lz4/lz4hc.h
build: Allow to use external liblz4 instead of embedded copy 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>
2014-08-12 00:37:33 -07:00
endif
evas: add a tgv loader. The TGV file format is specifically created for Evas. It is designed to allow region decompression and parallele decompression with a fast path for GPU that do handle ETC1 compression. Plan for adding other compression method will come later.
2014-03-11 03:08:40 -07:00
lib_evas_libevas_la_CPPFLAGS += \
-I$(top_srcdir)/src/static_libs/rg_etc \
@evas_image_loader_tgv_cflags@
build: Allow to use external liblz4 instead of embedded copy 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>
2014-08-12 00:37:33 -07:00
if ! ENABLE_LIBLZ4
lib_evas_libevas_la_CPPFLAGS += \
-I$(top_srcdir)/src/static_libs/lz4
endif
evas: add a tgv loader. The TGV file format is specifically created for Evas. It is designed to allow region decompression and parallele decompression with a fast path for GPU that do handle ETC1 compression. Plan for adding other compression method will come later.
2014-03-11 03:08:40 -07:00
lib_evas_libevas_la_LIBADD += @evas_image_loader_tgv_libs@
if EVAS_CSERVE2
bin_evas_evas_cserve2_slave_SOURCES += \
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules/evas/image_loaders/tgv/evas_image_load_tgv.c \
evas: add a tgv loader. The TGV file format is specifically created for Evas. It is designed to allow region decompression and parallele decompression with a fast path for GPU that do handle ETC1 compression. Plan for adding other compression method will come later.
2014-03-11 03:08:40 -07:00
static_libs/rg_etc/rg_etc1.c \
Evas rg_etc2: Add ETC2 decoding routines Simple implementation of the OpenGL ES 3.0 specification, annex C.1.
2014-04-29 22:10:33 -07:00
static_libs/rg_etc/rg_etc2.c \
build: Allow to use external liblz4 instead of embedded copy 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>
2014-08-12 00:37:33 -07:00
static_libs/rg_etc/rg_etc1.h
if ! ENABLE_LIBLZ4
bin_evas_evas_cserve2_slave_SOURCES += \
evas: add a tgv loader. The TGV file format is specifically created for Evas. It is designed to allow region decompression and parallele decompression with a fast path for GPU that do handle ETC1 compression. Plan for adding other compression method will come later.
2014-03-11 03:08:40 -07:00
static_libs/lz4/lz4.c \
static_libs/lz4/lz4.h
build: Allow to use external liblz4 instead of embedded copy 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>
2014-08-12 00:37:33 -07:00
endif
evas: add a tgv loader. The TGV file format is specifically created for Evas. It is designed to allow region decompression and parallele decompression with a fast path for GPU that do handle ETC1 compression. Plan for adding other compression method will come later.
2014-03-11 03:08:40 -07:00
bin_evas_evas_cserve2_slave_CPPFLAGS += \
-I$(top_builddir)/src/lib/efl \
-I$(top_srcdir)/src/static_libs/rg_etc \
-I$(top_srcdir)/src/lib/evas/ \
autotools: fix build with NEON support.
2014-10-28 16:12:06 -07:00
@evas_image_loader_tgv_cflags@ \
@NEON_CFLAGS@
build: Allow to use external liblz4 instead of embedded copy 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>
2014-08-12 00:37:33 -07:00
if ! ENABLE_LIBLZ4
bin_evas_evas_cserve2_slave_CPPFLAGS += \
-I$(top_srcdir)/src/static_libs/lz4
endif
evas: add a tgv loader. The TGV file format is specifically created for Evas. It is designed to allow region decompression and parallele decompression with a fast path for GPU that do handle ETC1 compression. Plan for adding other compression method will come later.
2014-03-11 03:08:40 -07:00
bin_evas_evas_cserve2_slave_LDADD += @evas_image_loader_tgv_libs@
endif
else
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
loadertgvpkgdir = $(libdir)/evas/modules/image_loaders/tgv/$(MODULE_ARCH)
loadertgvpkg_LTLIBRARIES = modules/evas/image_loaders/tgv/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_loadertgvpkgLTLIBRARIES = install-loadertgvpkgLTLIBRARIES
$(install_loadertgvpkgLTLIBRARIES): install-libLTLIBRARIES
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_tgv_module_la_SOURCES = \
modules/evas/image_loaders/tgv/evas_image_load_tgv.c \
evas: add a tgv loader. The TGV file format is specifically created for Evas. It is designed to allow region decompression and parallele decompression with a fast path for GPU that do handle ETC1 compression. Plan for adding other compression method will come later.
2014-03-11 03:08:40 -07:00
static_libs/rg_etc/rg_etc1.c \
Evas rg_etc2: Add ETC2 decoding routines Simple implementation of the OpenGL ES 3.0 specification, annex C.1.
2014-04-29 22:10:33 -07:00
static_libs/rg_etc/rg_etc2.c \
build: Allow to use external liblz4 instead of embedded copy 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>
2014-08-12 00:37:33 -07:00
static_libs/rg_etc/rg_etc1.h
if ! ENABLE_LIBLZ4
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_tgv_module_la_SOURCES += \
evas: add a tgv loader. The TGV file format is specifically created for Evas. It is designed to allow region decompression and parallele decompression with a fast path for GPU that do handle ETC1 compression. Plan for adding other compression method will come later.
2014-03-11 03:08:40 -07:00
static_libs/lz4/lz4.c \
static_libs/lz4/lz4.h
build: Allow to use external liblz4 instead of embedded copy 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>
2014-08-12 00:37:33 -07:00
endif
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_tgv_module_la_CPPFLAGS = \
evas: add a tgv loader. The TGV file format is specifically created for Evas. It is designed to allow region decompression and parallele decompression with a fast path for GPU that do handle ETC1 compression. Plan for adding other compression method will come later.
2014-03-11 03:08:40 -07:00
-I$(top_builddir)/src/lib/efl \
-I$(top_srcdir)/src/static_libs/rg_etc \
-I$(top_srcdir)/src/lib/evas/ \
@EVAS_CFLAGS@ \
autotools: fix build with NEON support.
2014-10-28 16:12:06 -07:00
@NEON_CFLAGS@ \
evas: add a tgv loader. The TGV file format is specifically created for Evas. It is designed to allow region decompression and parallele decompression with a fast path for GPU that do handle ETC1 compression. Plan for adding other compression method will come later.
2014-03-11 03:08:40 -07:00
@evas_image_loader_tgv_cflags@
build: Allow to use external liblz4 instead of embedded copy 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>
2014-08-12 00:37:33 -07:00
if ! ENABLE_LIBLZ4
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_tgv_module_la_CPPFLAGS += \
build: Allow to use external liblz4 instead of embedded copy 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>
2014-08-12 00:37:33 -07:00
-I$(top_srcdir)/src/static_libs/lz4
endif
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_tgv_module_la_LIBADD = \
evas: add a tgv loader. The TGV file format is specifically created for Evas. It is designed to allow region decompression and parallele decompression with a fast path for GPU that do handle ETC1 compression. Plan for adding other compression method will come later.
2014-03-11 03:08:40 -07:00
@USE_EVAS_LIBS@ \
@evas_image_loader_tgv_libs@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_loaders_tgv_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_image_loaders_tgv_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_image_loaders_tgv_module_la_LIBTOOLFLAGS = --tag=disable-static
savertgvpkgdir = $(libdir)/evas/modules/image_savers/tgv/$(MODULE_ARCH)
savertgvpkg_LTLIBRARIES = modules/evas/image_savers/tgv/module.la
build: Workaround an automake limitation during parallel install relinking 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.
2015-02-26 03:35:50 -08:00
# Workaround for broken parallel install support in automake (relink issue)
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7328
install_savertgvpkgLTLIBRARIES = install-savertgvpkgLTLIBRARIES
$(install_savertgvpkgLTLIBRARIES): install-libLTLIBRARIES
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_savers_tgv_module_la_SOURCES = \
modules/evas/image_savers/tgv/evas_image_save_tgv.c \
evas: add TGV saver module.
2014-03-12 00:32:17 -07:00
static_libs/rg_etc/rg_etc1.c \
static_libs/rg_etc/rg_etc1.h \
build: Allow to use external liblz4 instead of embedded copy 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>
2014-08-12 00:37:33 -07:00
static_libs/rg_etc/etc2_encoder.c
if ! ENABLE_LIBLZ4
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_savers_tgv_module_la_SOURCES += \
evas: add TGV saver module.
2014-03-12 00:32:17 -07:00
static_libs/lz4/lz4.c \
Evas ETC1: Use LZ4HC for higher compression ratios LZ4HC has a higher compression ratio than LZ4 but basically the same decompression speed. The performance cost during encoding is actually still pretty low considering how expensive ETC1 compression can be (even at medium quality).
2014-04-14 19:41:16 -07:00
static_libs/lz4/lz4.h \
static_libs/lz4/lz4hc.c \
static_libs/lz4/lz4hc.h
build: Allow to use external liblz4 instead of embedded copy 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>
2014-08-12 00:37:33 -07:00
endif
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_savers_tgv_module_la_CPPFLAGS = \
evas: add TGV saver module.
2014-03-12 00:32:17 -07:00
-I$(top_builddir)/src/lib/efl \
-I$(top_srcdir)/src/static_libs/rg_etc \
-I$(top_srcdir)/src/lib/evas/ \
@EVAS_CFLAGS@ \
@evas_image_saver_tgv_cflags@
build: Allow to use external liblz4 instead of embedded copy 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>
2014-08-12 00:37:33 -07:00
if ! ENABLE_LIBLZ4
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_savers_tgv_module_la_CPPFLAGS += \
build: Allow to use external liblz4 instead of embedded copy 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>
2014-08-12 00:37:33 -07:00
-I$(top_srcdir)/src/static_libs/lz4
endif
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_savers_tgv_module_la_LIBADD = \
evas: add TGV saver module.
2014-03-12 00:32:17 -07:00
@USE_EVAS_LIBS@ \
@evas_image_saver_tgv_libs@
evas: preparation of places for model_saver_loader separated from image_saver_loader.
2014-11-26 08:50:43 -08:00
modules_evas_image_savers_tgv_module_la_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
modules_evas_image_savers_tgv_module_la_LDFLAGS = -module @EFL_LTMODULE_FLAGS@
modules_evas_image_savers_tgv_module_la_LIBTOOLFLAGS = --tag=disable-static
evas: add a tgv loader. The TGV file format is specifically created for Evas. It is designed to allow region decompression and parallele decompression with a fast path for GPU that do handle ETC1 compression. Plan for adding other compression method will come later.
2014-03-11 03:08:40 -07:00
endif
endif
merge: and now Evas 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
2012-11-04 03:51:42 -08:00
merge: do not use recursive make for unit tests SVN revision: 79413
2012-11-17 23:12:38 -08:00
### Unit tests
if EFL_ENABLE_TESTS
check_PROGRAMS += tests/evas/evas_suite
efl: use autotools testsuite for running tests 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
2013-01-15 12:51:04 -08:00
TESTS += tests/evas/evas_suite
merge: do not use recursive make for unit tests SVN revision: 79413
2012-11-17 23:12:38 -08:00
tests_evas_evas_suite_SOURCES = \
tests/evas/evas_suite.c \
tests/evas/evas_test_init.c \
Evas tests: Add canvas free with ref tests. This should check test for the issue fixed in: bb4a19b5ad6a8fc6720154700aabfa32f4b71244 8bba92fbca7c721a7582b098698404e491f44941
2013-11-26 04:26:30 -08:00
tests/evas/evas_test_object.c \
Evas object: Add paragraph_direciton APIs Summary: It adds evas_object_paragraph_direction_set, get APIs. The APIs set or get paragraph direction to/from the given object. It changes BiDi calculations and affect the direction and aligning of text. It doesn't have any effect to text without Fribidi library. The default paragraph direction is EVAS_BIDI_DIRECTION_INHERIT. If dir is EVAS_BIDI_DIRECTION_INHERIT, paragraph direction is changed according to smart parent object. If there is no smart parent object, paragraph direction works as EVAS_BIDI_DIRECTION_NEUTRAL. @feature Test Plan: Test cases included to the following files. - evas_test_textblock.c - evas_test_text.c - evas_test_object_smart.c Run "make check". Reviewers: woohyun, raster, herdsman, tasn Subscribers: c, raster, cedric Differential Revision: https://phab.enlightenment.org/D1690
2015-11-19 03:37:07 -08:00
tests/evas/evas_test_object_smart.c \
merge: do not use recursive make for unit tests SVN revision: 79413
2012-11-17 23:12:38 -08:00
tests/evas/evas_test_textblock.c \
tests/evas/evas_test_text.c \
tests/evas/evas_test_callbacks.c \
efl: make libraries aware of EFL_RUN_IN_TREE. this variable tells that the build is being done in tree and we should not look at install locations. SVN revision: 82217
2013-01-04 09:19:43 -08:00
tests/evas/evas_test_render_engines.c \
Evas filters: Add test cases for the script parser Basic syntax checks and instructions coverage.
2014-02-17 19:35:24 -08:00
tests/evas/evas_test_filters.c \
evas: add infrastructure and basic tests for loading image.
2014-03-14 00:00:57 -07:00
tests/evas/evas_test_image.c \
evas: Evas_3D - add .eet export/import 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>
2014-10-06 07:27:06 -07:00
tests/evas/evas_test_mesh.c \
Evas masking: Add some test cases 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.
2015-01-05 23:58:33 -08:00
tests/evas/evas_test_mask.c \
Evas GL: Add a test case for Evas GL (make check) For now this only covers SOME of Evas GL's functions. It will try to run with opengl_x11 and buffer (OSMesa). It'll also try to fail silently if the engine initialization failed, or if OSMesa could not be found. If the engines work, then Evas GL must work properly.
2015-10-14 01:30:25 -07:00
tests/evas/evas_test_evasgl.c \
evas: fix bug with logic with eina_matrix in evas_3d_utils Summary: Also need to fix logically dead code in coverity. Reviewers: raster, Hermet, cedric Subscribers: jpeg Maniphest Tasks: T2832 Differential Revision: https://phab.enlightenment.org/D3346 Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
2015-12-02 14:14:17 -08:00
tests/evas/evas_test_matrix.c \
merge: do not use recursive make for unit tests SVN revision: 79413
2012-11-17 23:12:38 -08:00
tests/evas/evas_tests_helpers.h \
tests/evas/evas_suite.h
add a global Efl_Config.h for everyone. * ned to replicate changes in other .pc.in files * need to replicate changes in other E*.h installed header files
2013-04-24 07:43:33 -07:00
tests_evas_evas_suite_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
Evas filters: Add render test cases with pixel verification Force render into an Ecore_Evas, and check that the pixels are valid: - Not all transparent (can't really happen) - Not all black (since there's a black rect behind the text) - All valid premultiplied values (A >= R,G,B) Yes, it's a bit slow. But at least it really checks something :)
2014-02-18 18:02:53 -08:00
-I$(top_srcdir)/src/lib/ecore_evas \
evas: Refactor evas filters a bit This is a preparation step for (experimental) textblock support. Textblock objects won't have a single filter, and the buffer's geometry wouldn't be that of of the object itself. Thus a few internal APIs need to be reworked first.
2016-12-22 02:41:04 -08:00
-I$(top_builddir)/src/lib/evas/canvas \
Evas text tests: Start shipping DejaVuSans with the test suite. We can finally rely on having fonts in all cases (even when there's no fontconfig) and we can also rely on specific sizing.
2013-02-25 06:58:22 -08:00
-DTESTS_SRC_DIR=\"$(top_srcdir)/src/tests/evas\" \
Evas tests: Fix TESTS_BUILD_DIR to point to the build dir.
2013-03-26 07:58:19 -07:00
-DTESTS_BUILD_DIR=\"$(top_builddir)/src/tests/evas\" \
merge: do not use recursive make for unit tests SVN revision: 79413
2012-11-17 23:12:38 -08:00
@CHECK_CFLAGS@ \
@EVAS_CFLAGS@
Evas filters: Add render test cases with pixel verification Force render into an Ecore_Evas, and check that the pixels are valid: - Not all transparent (can't really happen) - Not all black (since there's a black rect behind the text) - All valid premultiplied values (A >= R,G,B) Yes, it's a bit slow. But at least it really checks something :)
2014-02-18 18:02:53 -08:00
tests_evas_evas_suite_LDADD = @CHECK_LIBS@ @USE_EVAS_LIBS@ @USE_ECORE_EVAS_LIBS@
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
tests_evas_evas_suite_DEPENDENCIES = @USE_EVAS_INTERNAL_LIBS@
merge: do not use recursive make for unit tests SVN revision: 79413
2012-11-17 23:12:38 -08:00
endif
Evas text tests: Start shipping DejaVuSans with the test suite. We can finally rely on having fonts in all cases (even when there's no fontconfig) and we can also rely on specific sizing.
2013-02-25 06:58:22 -08:00
build: split EXTRA_DIST files in src/ off from DISTFILES and handle separately This is again to avoid the "Argument list too long" error we are hitting more and more now. Given we just merged elementary, emotion generic players, evas generic loaders and elm_code it is not surprising we are hitting it again. This time the number of files being hold in DISTFILES has just grown to big so a make dist was no longer possible. If one looks at what the DISTFILES variable from automake holds you can image it grows a lot with all the source files plus generated files we have in tree now. DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) To cut off a big chunk but still keep all the other automagic in place for SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle the files in a dist-hook now. Another thing to note here is that this also only happens as we have the one big Makefile with includes. If we go back to per directory Makefiles this problem should vanish as well. In any case we need a solution for 1.18 now and this is what I have to offer. If you have a cleaner solution in mind feel welcome to test it out and if everything we need keeps working (make, make examples, make check, make benchmark, make dist and make distcheck) go ahead.
2016-06-08 01:26:06 -07:00
EXTRA_DIST2 += \
evas: update file path after move into fonts subdir The file have been moved into a fonts subdir in commit e8b35c779e7d7b. Update the path here to get it included into the tarball to make sure check passes during distcheck.
2017-07-11 12:54:25 -07:00
tests/evas/fonts/TestFont.eet \
evas: Add a test case with a custom font The font is **ugly** and was created with birdfont. Its license shall be anything EFL requires (public domain in the ttf file).
2017-07-11 00:02:59 -07:00
tests/evas/fonts/evas_test_font.ttf \
build: Give correct path for test files Another breakage coming in with the rg_etc changes. Image files have been missing the correct location to pick them up for distcheck.
2014-04-08 02:06:49 -07:00
tests/evas/images/HM7Y9233-50.tgv \
tests/evas/images/HM7Y9233.jpg \
tests/evas: Add missing files to EXTRA_DIST and remove duplicates 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.
2014-10-21 00:57:13 -07:00
tests/evas/images/Light-50.png \
build: Give correct path for test files Another breakage coming in with the rg_etc changes. Image files have been missing the correct location to pick them up for distcheck.
2014-04-08 02:06:49 -07:00
tests/evas/images/Light-50.tgv \
tests/evas/images/Light.jpg \
jpeg laoder: exif orientation test added Summary: currently, normal orientation tests are only added. I'm going to add flipped orientation tests as well after I put related code in jpeg loader (currently it's not supported) Reviewers: raster, cedric, jpeg CC: seoz, cedric Differential Revision: https://phab.enlightenment.org/D1098
2014-06-29 04:04:16 -07:00
tests/evas/images/Light_exif.jpg \
tests/evas/images/Light_exif_90.jpg \
tests/evas/images/Light_exif_180.jpg \
tests/evas/images/Light_exif_270.jpg \
tests/evas: Add missing files to EXTRA_DIST and remove duplicates 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.
2014-10-21 00:57:13 -07:00
tests/evas/images/Pic1-10.png \
build: Give correct path for test files Another breakage coming in with the rg_etc changes. Image files have been missing the correct location to pick them up for distcheck.
2014-04-08 02:06:49 -07:00
tests/evas/images/Pic1-10.tgv \
tests/evas: Add missing files to EXTRA_DIST and remove duplicates 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.
2014-10-21 00:57:13 -07:00
tests/evas/images/Pic1-100.png \
build: Give correct path for test files Another breakage coming in with the rg_etc changes. Image files have been missing the correct location to pick them up for distcheck.
2014-04-08 02:06:49 -07:00
tests/evas/images/Pic1-100.tgv \
tests/evas: Add missing files to EXTRA_DIST and remove duplicates 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.
2014-10-21 00:57:13 -07:00
tests/evas/images/Pic1-50.png \
build: Give correct path for test files Another breakage coming in with the rg_etc changes. Image files have been missing the correct location to pick them up for distcheck.
2014-04-08 02:06:49 -07:00
tests/evas/images/Pic1-50.tgv \
tests/evas/images/Pic1.png \
tests/evas: Add missing files to EXTRA_DIST and remove duplicates 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.
2014-10-21 00:57:13 -07:00
tests/evas/images/Pic4-10.png \
build: Give correct path for test files Another breakage coming in with the rg_etc changes. Image files have been missing the correct location to pick them up for distcheck.
2014-04-08 02:06:49 -07:00
tests/evas/images/Pic4-10.tgv \
tests/evas: Add missing files to EXTRA_DIST and remove duplicates 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.
2014-10-21 00:57:13 -07:00
tests/evas/images/Pic4-100.png \
build: Give correct path for test files Another breakage coming in with the rg_etc changes. Image files have been missing the correct location to pick them up for distcheck.
2014-04-08 02:06:49 -07:00
tests/evas/images/Pic4-100.tgv \
tests/evas: Add missing files to EXTRA_DIST and remove duplicates 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.
2014-10-21 00:57:13 -07:00
tests/evas/images/Pic4-50.png \
build: Give correct path for test files Another breakage coming in with the rg_etc changes. Image files have been missing the correct location to pick them up for distcheck.
2014-04-08 02:06:49 -07:00
tests/evas/images/Pic4-50.tgv \
tests/evas/images/Pic4.png \
tests/evas/images/Sunrise-100.tgv \
tests/evas/images/Temple-10.tgv \
tests/evas/images/Temple.jpg \
tests/evas/images/Temple3-10.tgv \
tests/evas/images/Temple3.jpg \
tests/evas: Add missing files to EXTRA_DIST and remove duplicates 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.
2014-10-21 00:57:13 -07:00
tests/evas/images/Train-10.png \
build: Give correct path for test files Another breakage coming in with the rg_etc changes. Image files have been missing the correct location to pick them up for distcheck.
2014-04-08 02:06:49 -07:00
tests/evas/images/Train-10.tgv \
tests/evas/images/Train.jpg \
autotools: missing files for make check in a make dist tarball.
2014-07-22 03:51:08 -07:00
tests/evas/images/mars_rover_panorama_half-size.jpg \
tests/evas/images/Light_exif_flip_h.jpg \
tests/evas/images/Light_exif_flip_v.jpg \
tests/evas/images/Light_exif_transpose.jpg \
tests/evas/images/Light_exif_transverse.jpg \
evas: tests more file format loader. NOTE: It seems that the xpm one is broken. If somebody could give it a better look and check if it work for him or not, before opening a bug in phab.
2014-10-21 07:46:12 -07:00
tests/evas/images/Pic4-bmp.png \
tests/evas/images/Pic4-dds.png \
tests/evas/images/Pic4-gif.png \
tests/evas/images/Pic4-png.png \
tests/evas/images/Pic4-psd.png \
tests/evas/images/Pic4-tga.png \
tests/evas/images/Pic4-wbmp.png \
tests/evas/images/Pic4-webp.png \
tests/evas/images/Pic4-xpm.png \
tests/evas/images/Pic4.bmp \
tests/evas/images/Pic4.dds \
tests/evas/images/Pic4.gif \
tests/evas/images/Pic4.psd \
tests/evas/images/Pic4.tga \
tests/evas/images/Pic4.wbmp \
tests/evas/images/Pic4.webp \
tests/evas/images/Pic4.xpm \
tests/evas: Add missing files to EXTRA_DIST and remove duplicates 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.
2014-10-21 00:57:13 -07:00
tests/evas/meshes/md2/sonic.md2 \
evas: check for grayscale png and jpeg.
2014-12-28 13:14:05 -08:00
tests/evas/meshes/obj/man_mesh.obj \
tests/evas/images/gray.jpg \
evas tests - add Jpeg2000 tests add tests for loading jp2k files correctly and the images
2017-08-11 01:51:29 -07:00
tests/evas/images/bg_gray.png \
build: evas: fix names of jpeg200 test images The suffix for both of them has been wrong.
2017-08-28 07:45:21 -07:00
tests/evas/images/flower.jp2 \
tests/evas/images/flower.jp2.png \
tests/evas/images/train.j2k \
tests/evas/images/train.j2k.png
autotools: missing files for make check in a make dist tarball.
2014-07-22 03:51:08 -07:00
elua/autotools: generate .eo.lua files out of all eo files at build time Also change the generator a bit so that it doesn't rely on lib name information and fix the runtime to properly source lua files within tree.
2014-10-06 03:32:25 -07:00
if HAVE_ELUA
elua, js: also update build after evas changes
2017-10-19 11:17:14 -07:00
evas_eolian_lua = $(evas_canvas_eolian_pub_files:%.eo=%.eo.lua) \
$(evas_gesture_eolian_pub_files:%.eo=%.eo.lua)
elua/autotools: generate .eo.lua files out of all eo files at build time Also change the generator a bit so that it doesn't rely on lib name information and fix the runtime to properly source lua files within tree.
2014-10-06 03:32:25 -07:00
generated_evas_lua_all = $(evas_eolian_lua)
build: clean generated js and lua files manually to avoid problems with CLEANFILES We hit another argument too long error with CLEANFILES. Moving the generated files for js and lua into separated variables and cleaning them manually fixes the issue.
2016-06-21 07:13:17 -07:00
GENERATED_LUA_BINDINGS += $(generated_evas_lua_all)
elua/autotools: generate .eo.lua files out of all eo files at build time Also change the generator a bit so that it doesn't rely on lib name information and fix the runtime to properly source lua files within tree.
2014-10-06 03:32:25 -07:00
installed_evasluadir = $(datadir)/elua/modules/evas
nodist_installed_evaslua_DATA = $(generated_evas_lua_all)
endif
Evas filters: Implement Lua classes for colors & buffer Reuse previous code for buffer. Keeps API stability. The new class "color" is here for a more convenient color representation. This way, colors can be represented in more natural ways like: {r,g,b[,a]}, 0xaarrggbb, "red", "#rrggbb" Class color is implemented in pure Lua, and adds a .lua file to Evas' share folder.
2015-06-04 03:42:38 -07:00
# Evas filters Lua stuff
evas_filters_lua = \
lib/evas/filters/lua/color.lua \
$(NULL)
installed_evasfiltersdir = $(datadir)/evas/filters/lua
dist_installed_evasfilters_DATA = $(evas_filters_lua)
efl-js: JavaScript Eolian binding 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
2014-09-01 11:08:49 -07:00
if HAVE_JS
elua, js: also update build after evas changes
2017-10-19 11:17:14 -07:00
generated_evas_js_bindings = $(evas_canvas_eolian_pub_files:%.eo=%.eo.js.cc) \
$(evas_gesture_eolian_pub_files:%.eo=%.eo.js.cc)
efl-js: JavaScript Eolian binding 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
2014-09-01 11:08:49 -07:00
GENERATED_JS_BINDINGS += $(generated_evas_js_bindings)
endif
c++: Reorganized C++ binding generation Moved all generation to a single Makefile_Cxx.am file instead of throughout the whole project. And fixed C++ generation on Elementary after elm merge.
2016-05-23 08:01:30 -07:00
efl-cxx: Fixes to make dist
2017-12-13 06:36:21 -08:00
if HAVE_CXX
cxx build: update after the evas gesture build fix The changes in f334f2a5042734218d599f189fda615db47be766 also need an update in the C++ build.
2017-10-19 11:11:49 -07:00
evas_canvas_eolian_cxx_hh = $(evas_canvas_eolian_pub_files:%.eo=%.eo.hh) \
$(evas_eolian_legacy_files:%.eo=%.eo.hh)
evas_canvas_eolian_cxx_impl_hh = $(evas_canvas_eolian_pub_files:%.eo=%.eo.impl.hh) \
$(evas_eolian_legacy_files:%.eo=%.eo.impl.hh)
evas_gesture_eolian_cxx_hh = $(evas_gesture_eolian_pub_files:%.eo=%.eo.hh)
evas_gesture_eolian_cxx_impl_hh = $(evas_gesture_eolian_pub_files:%.eo=%.eo.impl.hh)
c++: Reorganized C++ binding generation Moved all generation to a single Makefile_Cxx.am file instead of throughout the whole project. And fixed C++ generation on Elementary after elm merge.
2016-05-23 08:01:30 -07:00
endif
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
build: split EXTRA_DIST files in src/ off from DISTFILES and handle separately This is again to avoid the "Argument list too long" error we are hitting more and more now. Given we just merged elementary, emotion generic players, evas generic loaders and elm_code it is not surprising we are hitting it again. This time the number of files being hold in DISTFILES has just grown to big so a make dist was no longer possible. If one looks at what the DISTFILES variable from automake holds you can image it grows a lot with all the source files plus generated files we have in tree now. DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) To cut off a big chunk but still keep all the other automagic in place for SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle the files in a dist-hook now. Another thing to note here is that this also only happens as we have the one big Makefile with includes. If we go back to per directory Makefiles this problem should vanish as well. In any case we need a solution for 1.18 now and this is what I have to offer. If you have a cleaner solution in mind feel welcome to test it out and if everything we need keeps working (make, make examples, make check, make benchmark, make dist and make distcheck) go ahead.
2016-06-08 01:26:06 -07:00
EXTRA_DIST2 += \
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
generic/evas/common/shmfile.c \
generic/evas/common/shmfile.h \
generic/evas/common/timeout.c \
generic/evas/common/timeout.h
evasgenericloadersdir = \
$(libdir)/evas/utils
evasgenericloaders_PROGRAMS =
evas: loaders fix typo which blocked the installation of the LO loader script Its SCRIPTS not SCRIPT to make automake aware of it. Fixes T3848
2016-06-13 08:20:58 -07:00
evasgenericloaders_SCRIPTS =
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
### Libreoffice converter to pdf
build: split EXTRA_DIST files in src/ off from DISTFILES and handle separately This is again to avoid the "Argument list too long" error we are hitting more and more now. Given we just merged elementary, emotion generic players, evas generic loaders and elm_code it is not surprising we are hitting it again. This time the number of files being hold in DISTFILES has just grown to big so a make dist was no longer possible. If one looks at what the DISTFILES variable from automake holds you can image it grows a lot with all the source files plus generated files we have in tree now. DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) To cut off a big chunk but still keep all the other automagic in place for SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle the files in a dist-hook now. Another thing to note here is that this also only happens as we have the one big Makefile with includes. If we go back to per directory Makefiles this problem should vanish as well. In any case we need a solution for 1.18 now and this is what I have to offer. If you have a cleaner solution in mind feel welcome to test it out and if everything we need keeps working (make, make examples, make check, make benchmark, make dist and make distcheck) go ahead.
2016-06-08 01:26:06 -07:00
EXTRA_DIST2 += generic/evas/pdf/evas_generic_pdf_loader.libreoffice
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
if HAVE_POPPLER
evas: loaders fix typo which blocked the installation of the LO loader script Its SCRIPTS not SCRIPT to make automake aware of it. Fixes T3848
2016-06-13 08:20:58 -07:00
evasgenericloaders_SCRIPTS += generic/evas/pdf/evas_generic_pdf_loader.libreoffice
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
evasgenericloaders_PROGRAMS += generic/evas/pdf/evas_image_loader.pdf
generic_evas_pdf_evas_image_loader_pdf_SOURCES = \
generic/evas/pdf/main.cpp \
generic/evas/common/shmfile.c \
generic/evas/common/timeout.c
generic_evas_pdf_evas_image_loader_pdf_CFLAGS = \
-I$(top_srcdir)/src/lib/efl \
Generic modules: Fix out of source build. Autotools really really really sucks. Because of the above, we need to manually list both source dirs and build dirs, because some of the include files are in the source dirs and some are in the build dir (generated).
2016-06-05 02:40:02 -07:00
-I$(top_builddir)/src/lib/efl \
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
-I$(top_srcdir)/src/lib/eina \
Generic modules: Fix out of source build. Autotools really really really sucks. Because of the above, we need to manually list both source dirs and build dirs, because some of the include files are in the source dirs and some are in the build dir (generated).
2016-06-05 02:40:02 -07:00
-I$(top_builddir)/src/lib/eina \
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
-I$(top_srcdir)/src/generic/evas/common \
@POPPLER_CFLAGS@
generic_evas_pdf_evas_image_loader_pdf_CXXFLAGS = \
-I$(top_srcdir)/src/lib/efl \
Generic modules: Fix out of source build. Autotools really really really sucks. Because of the above, we need to manually list both source dirs and build dirs, because some of the include files are in the source dirs and some are in the build dir (generated).
2016-06-05 02:40:02 -07:00
-I$(top_builddir)/src/lib/efl \
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
-I$(top_srcdir)/src/lib/eina \
Generic modules: Fix out of source build. Autotools really really really sucks. Because of the above, we need to manually list both source dirs and build dirs, because some of the include files are in the source dirs and some are in the build dir (generated).
2016-06-05 02:40:02 -07:00
-I$(top_builddir)/src/lib/eina \
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
-I$(top_srcdir)/src/generic/evas/common \
@POPPLER_CFLAGS@
evas: correctly handle dependencies of evas generic loaders.
2016-06-02 10:43:04 -07:00
generic_evas_pdf_evas_image_loader_pdf_LDADD = @USE_EINA_LIBS@ @POPPLER_LIBS@ @SHM_LIBS@
generic_evas_pdf_evas_image_loader_pdf_DEPENDENCIES = @USE_EINA_INTERNAL_LIBS@
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
EFL_INSTALL_EXEC_HOOK += \
evas: loaders: fix install exec hook by adding the needed semicolon Thanks to Scimmia22 for pointing this out.
2016-06-13 08:07:28 -07:00
mkdir -p $(DESTDIR)$(libdir)/evas/utils; \
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
ln -sf evas_image_loader.pdf $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.ppt; \
ln -sf evas_image_loader.pdf $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.pptx; \
ln -sf evas_image_loader.pdf $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.odp; \
ln -sf evas_image_loader.pdf $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.xls; \
ln -sf evas_image_loader.pdf $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.xlsx; \
ln -sf evas_image_loader.pdf $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.ods; \
ln -sf evas_image_loader.pdf $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.doc; \
ln -sf evas_image_loader.pdf $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.docx; \
ln -sf evas_image_loader.pdf $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.odt; \
ln -sf evas_image_loader.pdf $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.rtf; \
ln -sf evas_generic_pdf_loader.libreoffice $(DESTDIR)$(libdir)/evas/utils/evas_generic_pdf_loader.ppt; \
ln -sf evas_generic_pdf_loader.libreoffice $(DESTDIR)$(libdir)/evas/utils/evas_generic_pdf_loader.pptx; \
ln -sf evas_generic_pdf_loader.libreoffice $(DESTDIR)$(libdir)/evas/utils/evas_generic_pdf_loader.odp; \
ln -sf evas_generic_pdf_loader.libreoffice $(DESTDIR)$(libdir)/evas/utils/evas_generic_pdf_loader.xls; \
ln -sf evas_generic_pdf_loader.libreoffice $(DESTDIR)$(libdir)/evas/utils/evas_generic_pdf_loader.xlsx; \
ln -sf evas_generic_pdf_loader.libreoffice $(DESTDIR)$(libdir)/evas/utils/evas_generic_pdf_loader.ods; \
ln -sf evas_generic_pdf_loader.libreoffice $(DESTDIR)$(libdir)/evas/utils/evas_generic_pdf_loader.doc; \
ln -sf evas_generic_pdf_loader.libreoffice $(DESTDIR)$(libdir)/evas/utils/evas_generic_pdf_loader.docx; \
ln -sf evas_generic_pdf_loader.libreoffice $(DESTDIR)$(libdir)/evas/utils/evas_generic_pdf_loader.odt; \
ln -sf evas_generic_pdf_loader.libreoffice $(DESTDIR)$(libdir)/evas/utils/evas_generic_pdf_loader.rtf;
endif
if HAVE_SPECTRE
evasgenericloaders_PROGRAMS += generic/evas/ps/evas_image_loader.ps
generic_evas_ps_evas_image_loader_ps_SOURCES = \
generic/evas/ps/main.c \
generic/evas/common/shmfile.c \
generic/evas/common/timeout.c
evas: correctly handle dependencies of evas generic loaders.
2016-06-02 10:43:04 -07:00
generic_evas_ps_evas_image_loader_ps_LDADD = @USE_EINA_LIBS@ @SPECTRE_LIBS@ @SHM_LIBS@
generic_evas_ps_evas_image_loader_ps_DEPENDENCIES = @USE_EINA_INTERNAL_LIBS@
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
generic_evas_ps_evas_image_loader_ps_CFLAGS = \
-I$(top_srcdir)/src/lib/efl \
Generic modules: Fix out of source build. Autotools really really really sucks. Because of the above, we need to manually list both source dirs and build dirs, because some of the include files are in the source dirs and some are in the build dir (generated).
2016-06-05 02:40:02 -07:00
-I$(top_builddir)/src/lib/efl \
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
-I$(top_srcdir)/src/lib/eina \
Generic modules: Fix out of source build. Autotools really really really sucks. Because of the above, we need to manually list both source dirs and build dirs, because some of the include files are in the source dirs and some are in the build dir (generated).
2016-06-05 02:40:02 -07:00
-I$(top_builddir)/src/lib/eina \
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
-I$(top_srcdir)/src/generic/evas/common
endif
if HAVE_LIBRAW
evasgenericloaders_PROGRAMS += generic/evas/raw/evas_image_loader.raw
generic_evas_raw_evas_image_loader_raw_SOURCES = \
generic/evas/raw/main.c \
generic/evas/common/shmfile.c \
generic/evas/common/timeout.c
evas: correctly handle dependencies of evas generic loaders.
2016-06-02 10:43:04 -07:00
generic_evas_raw_evas_image_loader_raw_LDADD = @USE_EINA_LIBS@ @SHM_LIBS@ @LIBRAW_LIBS@ -lm
generic_evas_raw_evas_image_loader_raw_DEPENDENCIES = @USE_EINA_INTERNAL_LIBS@
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
generic_evas_raw_evas_image_loader_raw_CFLAGS = \
-I$(top_srcdir)/src/lib/efl \
Generic modules: Fix out of source build. Autotools really really really sucks. Because of the above, we need to manually list both source dirs and build dirs, because some of the include files are in the source dirs and some are in the build dir (generated).
2016-06-05 02:40:02 -07:00
-I$(top_builddir)/src/lib/efl \
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
-I$(top_srcdir)/src/lib/eina \
Generic modules: Fix out of source build. Autotools really really really sucks. Because of the above, we need to manually list both source dirs and build dirs, because some of the include files are in the source dirs and some are in the build dir (generated).
2016-06-05 02:40:02 -07:00
-I$(top_builddir)/src/lib/eina \
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
-I$(top_srcdir)/src/generic/evas/common \
@LIBRAW_CFLAGS@
EFL_INSTALL_EXEC_HOOK += \
evas: loaders: fix install exec hook by adding the needed semicolon Thanks to Scimmia22 for pointing this out.
2016-06-13 08:07:28 -07:00
mkdir -p $(DESTDIR)$(libdir)/evas/utils; \
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
ln -sf evas_image_loader.raw $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.arw; \
ln -sf evas_image_loader.raw $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.cr2; \
ln -sf evas_image_loader.raw $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.crw; \
ln -sf evas_image_loader.raw $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.dcr; \
ln -sf evas_image_loader.raw $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.dng; \
ln -sf evas_image_loader.raw $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.k25; \
ln -sf evas_image_loader.raw $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.kdc; \
ln -sf evas_image_loader.raw $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.erf; \
ln -sf evas_image_loader.raw $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.mrw; \
ln -sf evas_image_loader.raw $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.nef; \
ln -sf evas_image_loader.raw $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.nrf; \
ln -sf evas_image_loader.raw $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.nrw; \
ln -sf evas_image_loader.raw $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.orf; \
ln -sf evas_image_loader.raw $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.rw2; \
ln -sf evas_image_loader.raw $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.pef; \
ln -sf evas_image_loader.raw $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.raf; \
ln -sf evas_image_loader.raw $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.sr2; \
ln -sf evas_image_loader.raw $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.srf; \
ln -sf evas_image_loader.raw $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.x3f;
endif
if HAVE_RSVG
evasgenericloaders_PROGRAMS += generic/evas/svg/evas_image_loader.svg
generic_evas_svg_evas_image_loader_svg_SOURCES = \
generic/evas/svg/main.c \
generic/evas/common/shmfile.c \
generic/evas/common/timeout.c
generic_evas_svg_evas_image_loader_svg_CFLAGS = \
-I$(top_srcdir)/src/lib/efl \
Generic modules: Fix out of source build. Autotools really really really sucks. Because of the above, we need to manually list both source dirs and build dirs, because some of the include files are in the source dirs and some are in the build dir (generated).
2016-06-05 02:40:02 -07:00
-I$(top_builddir)/src/lib/efl \
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
-I$(top_srcdir)/src/lib/eina \
Generic modules: Fix out of source build. Autotools really really really sucks. Because of the above, we need to manually list both source dirs and build dirs, because some of the include files are in the source dirs and some are in the build dir (generated).
2016-06-05 02:40:02 -07:00
-I$(top_builddir)/src/lib/eina \
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
-I$(top_srcdir)/src/generic/evas/common \
@RSVG_CFLAGS@
evas: correctly handle dependencies of evas generic loaders.
2016-06-02 10:43:04 -07:00
generic_evas_svg_evas_image_loader_svg_LDADD = @USE_EINA_LIBS@ @RSVG_LIBS@ @SHM_LIBS@ -lm
generic_evas_svg_evas_image_loader_svg_DEPENDENCIES = @USE_EINA_INTERNAL_LIBS@
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
EFL_INSTALL_EXEC_HOOK += \
evas: loaders: fix install exec hook by adding the needed semicolon Thanks to Scimmia22 for pointing this out.
2016-06-13 08:07:28 -07:00
mkdir -p $(DESTDIR)$(libdir)/evas/utils; \
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
ln -sf evas_image_loader.svg $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.svgz; \
ln -sf evas_image_loader.svg $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.svg.gz;
endif
build: split EXTRA_DIST files in src/ off from DISTFILES and handle separately This is again to avoid the "Argument list too long" error we are hitting more and more now. Given we just merged elementary, emotion generic players, evas generic loaders and elm_code it is not surprising we are hitting it again. This time the number of files being hold in DISTFILES has just grown to big so a make dist was no longer possible. If one looks at what the DISTFILES variable from automake holds you can image it grows a lot with all the source files plus generated files we have in tree now. DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) To cut off a big chunk but still keep all the other automagic in place for SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle the files in a dist-hook now. Another thing to note here is that this also only happens as we have the one big Makefile with includes. If we go back to per directory Makefiles this problem should vanish as well. In any case we need a solution for 1.18 now and this is what I have to offer. If you have a cleaner solution in mind feel welcome to test it out and if everything we need keeps working (make, make examples, make check, make benchmark, make dist and make distcheck) go ahead.
2016-06-08 01:26:06 -07:00
EXTRA_DIST2 += generic/evas/xcf/common.h
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
Disable XCF module on Windows Summary: This fixes compilation on Windows: timeout.c is using SIGALRM which is unavailable on Windows Test Plan: compilation Reviewers: cedric, jpeg, stefan_schmidt Differential Revision: https://phab.enlightenment.org/D4058
2016-06-16 06:59:28 -07:00
if HAVE_XCF
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
evasgenericloaders_PROGRAMS += generic/evas/xcf/evas_image_loader.xcf
generic_evas_xcf_evas_image_loader_xcf_SOURCES = \
generic/evas/xcf/main.c \
generic/evas/xcf/pixelfuncs.c \
generic/evas/common/shmfile.c \
generic/evas/common/timeout.c
generic_evas_xcf_evas_image_loader_xcf_CFLAGS = \
geneirc loader build patches for windows from T3790 - xcf.diff
2016-06-14 22:53:01 -07:00
@EVAS_CFLAGS@ \
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
-I$(top_srcdir)/src/lib/efl \
-I$(top_srcdir)/src/lib/eina \
Generic modules: Fix out of source build. Autotools really really really sucks. Because of the above, we need to manually list both source dirs and build dirs, because some of the include files are in the source dirs and some are in the build dir (generated).
2016-06-05 02:40:02 -07:00
-I$(top_builddir)/src/lib/eina \
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
-I$(top_srcdir)/src/generic/evas/common
evas: correctly handle dependencies of evas generic loaders.
2016-06-02 10:43:04 -07:00
generic_evas_xcf_evas_image_loader_xcf_LDADD = @USE_EINA_LIBS@ @SHM_LIBS@ -lm -lz
generic_evas_xcf_evas_image_loader_xcf_DEPENDENCIES = @USE_EINA_INTERNAL_LIBS@
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
EFL_INSTALL_EXEC_HOOK += \
evas: loaders: fix install exec hook by adding the needed semicolon Thanks to Scimmia22 for pointing this out.
2016-06-13 08:07:28 -07:00
mkdir -p $(DESTDIR)$(libdir)/evas/utils; \
evas: integrate evas generic loaders into our single tree build system.
2016-06-01 16:59:02 -07:00
ln -sf evas_image_loader.xcf $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.xcf.gz;
Disable XCF module on Windows Summary: This fixes compilation on Windows: timeout.c is using SIGALRM which is unavailable on Windows Test Plan: compilation Reviewers: cedric, jpeg, stefan_schmidt Differential Revision: https://phab.enlightenment.org/D4058
2016-06-16 06:59:28 -07:00
endif
efl - when evas generic loaders merged the gst loader was missed. fix this fixes the missing gst loader from generic loaders.
2016-07-24 23:21:45 -07:00
EXTRA_DIST2 += \
generic/evas/gst/main_0_10.c \
generic/evas/gst/main.c
if HAVE_GSTREAMER
EFL_INSTALL_EXEC_HOOK += \
mkdir -p $(DESTDIR)$(libdir)/evas/utils; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.264; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.3g2; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.3gp; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.3gp2; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.3gpp; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.3gpp2; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.3p2; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.asf; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.avi; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.bdm; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.bdmv; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.clpi; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.cpi; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.dv; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.fla; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.flv; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.m1v; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.m2t; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.m2v; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.m4v; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.mkv; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.mov; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.mp2; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.mp2ts; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.mp4; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.mpe; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.mpeg; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.mpg; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.mpl; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.mpls; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.mts; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.mxf; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.nut; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.nuv; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.ogg; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.ogm; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.ogv; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.qt; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.rm; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.rmj; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.rmm; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.rms; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.rmx; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.rmvb; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.rv; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.swf; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.ts; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.webm; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.weba; \
ln -sf evas_image_loader.gst $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.wmv;
endif
if HAVE_GSTREAMER0
evasgenericloaders_PROGRAMS += generic/evas/gst/evas_image_loader.gst
generic_evas_gst_evas_image_loader_gst_SOURCES = \
generic/evas/gst/main_0_10.c \
generic/evas/common/shmfile.c \
generic/evas/common/timeout.c
generic_evas_gst_evas_image_loader_gst_CFLAGS = \
-I$(top_srcdir)/src/lib/efl \
-I$(top_builddir)/src/lib/efl \
-I$(top_srcdir)/src/lib/eina \
-I$(top_builddir)/src/lib/eina \
-I$(top_srcdir)/src/generic/evas/common \
@EMOTION_MODULE_GSTREAMER_CFLAGS@
generic_evas_gst_evas_image_loader_gst_LDADD = \
@USE_EINA_LIBS@ @SHM_LIBS@ -lm @EMOTION_MODULE_GSTREAMER_LIBS@
generic_evas_gst_evas_image_loader_gst_DEPENDENCIES = @USE_EINA_INTERNAL_LIBS@
endif
if HAVE_GSTREAMER1
evasgenericloaders_PROGRAMS += generic/evas/gst/evas_image_loader.gst
generic_evas_gst_evas_image_loader_gst_SOURCES = \
generic/evas/gst/main.c \
generic/evas/common/shmfile.c \
generic/evas/common/timeout.c
generic_evas_gst_evas_image_loader_gst_CFLAGS = \
-I$(top_srcdir)/src/lib/efl \
-I$(top_builddir)/src/lib/efl \
-I$(top_srcdir)/src/lib/eina \
-I$(top_builddir)/src/lib/eina \
-I$(top_srcdir)/src/generic/evas/common \
@EMOTION_MODULE_GSTREAMER1_CFLAGS@
generic_evas_gst_evas_image_loader_gst_LDADD = \
@USE_EINA_LIBS@ @SHM_LIBS@ -lm @EMOTION_MODULE_GSTREAMER1_LIBS@
generic_evas_gst_evas_image_loader_gst_DEPENDENCIES = @USE_EINA_INTERNAL_LIBS@
endif