summaryrefslogtreecommitdiff
path: root/src/Makefile_Ecore_Evas.am (follow)
AgeCommit message (Collapse)Author
2013-05-14Start on ecore_evas Drm code.Chris Michael
Signed-off-by: Chris Michael <cp.michael@samsung.com>
2013-04-24add a global Efl_Config.h for everyone.Carsten Haitzler (Rasterman)
* ned to replicate changes in other .pc.in files * need to replicate changes in other E*.h installed header files
2013-03-23update po's ... :/Carsten Haitzler (Rasterman)
2013-03-12ecore_evas: re-order inclusion of header to fix compilation on Windows.Cedric Bail
It is a very tricky things to get header order right on windows. Having that order only in .c files simplify the work a lot. So let's try to do it with Ecore_Evas after it rewrite and split into modules.
2013-01-19fix missing linkage with -lrt for shm_open users.Gustavo Sverzut Barbieri
strange that nobody except hdante noticed this before, but it was missing linkage with -lrt in libemotion (due generic being static) and ecore_evas/extn. SVN revision: 83007
2013-01-16fix --enable-sdl compilation.Gustavo Sverzut Barbieri
Patch by Arvind R. SVN revision: 82896
2013-01-16each module install headers in their own directory.Gustavo Sverzut Barbieri
SVN revision: 82895
2013-01-14efl: simplify automake.Gustavo Sverzut Barbieri
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-11efl/ecore_evas: merge buffer into core, split extn apart.Gustavo Sverzut Barbieri
buffer is lightweight and dependency for many engines, merge it back into core. extn is a module on its own, and it's the only one linking to ecore_ipc, no need to add that to ecore_evas. minor cosmetic changes to configure to make output consistent. SVN revision: 82648
2013-01-04efl: make libraries aware of EFL_RUN_IN_TREE.Gustavo Sverzut Barbieri
this variable tells that the build is being done in tree and we should not look at install locations. SVN revision: 82217
2012-12-31efl: unbreak last commit.Gustavo Sverzut Barbieri
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-31efl: create macro to simplify libtool module declaration.Gustavo Sverzut Barbieri
SVN revision: 81916
2012-12-31efl: refactor CFLAGS, LIBS, LIBADD and LDADD usage.Gustavo Sverzut Barbieri
- 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-30efl: unify LDFLAGS for LTLIBRARIESGustavo Sverzut Barbieri
SVN revision: 81911
2012-12-20efl: simplify linkage/usage of evil on windows.Gustavo Sverzut Barbieri
instead of spreading it all around, just define 2 AC_SUBST() that will do the work. SVN revision: 81477
2012-12-19cleaning: remove unneeded $(top_builddir)Vincent Torri
SVN revision: 81324
2012-12-18sorry vincent. i know you dont like thus, but with this commit eflCarsten Haitzler
tree simply is broken and doesnt compile. error here: ... src/Makefile_Evas.am:1809: unterminated conditionals: HAVE_WINDOWS_TRUE src/Makefile.am:24: src/Makefile_Evas.am' included from here src/Makefile.am:128: unterminated conditionals: HAVE_WINDOWS_TRUE src/Makefile.am: installing ./depcomp' automake: #################### automake: ## Internal Error ## automake: #################### automake: undefined condition TRUE' for RECURSIVE_TARGETS' automake: RECURSIVE_TARGETS: automake: { automake: HAVE_WINDOWS => { automake: type: += automake: where: /usr/share/automake-1.11/am/texinfos.am: automake: comment: automake: value: dvi-recursive html-recursive info-recursive pdf-recursive ps-recursive \ automake: install-dvi-recursive \ automake: install-html-recursive \ automake: install-info-recursive \ automake: install-pdf-recursive \ automake: install-ps-recursive all-recursive check-recursive installcheck-recursive automake: owner: Automake automake: } automake: } automake: automake: Please contact <bug-automake@gnu.org>. at /usr/share/automake-1.11/Automake/Channels.pm line 657 Automake::Channels::msg('automake', '', 'undefined condition TRUE\' for RECURSIVE_TARGETS\'\x{a}RECURSIV...') called at /usr/share/automake-1.11/Automake/ChannelDefs.pm line 208 Automake::ChannelDefs::prog_error('undefined condition TRUE\' for RECURSIVE_TARGETS\'\x{a}RECURSIV...') called at /usr/share/automake-1.11/Automake/Item.pm line 94 Automake::Item::rdef('Automake::Variable=HASH(0x38cbe20)', 'Automake::Condition=HASH(0x2832a48)') called at /usr/bin/automake line 4102 Automake::handle_subdirs() called at /usr/bin/automake line 8305 Automake::generate_makefile('src/Makefile.am', 'src/Makefile.in') called at /usr/bin/automake line 8602 Automake::handle_makefile('src/Makefile.in') called at /usr/bin/automake line 8616 Automake::handle_makefiles_serial() called at /usr/bin/automake line 8769 autoreconf: automake failed with exit status: 255 ... i looked at the HAVE_WINDOWS if's and it seems fine to me - i couldnt find what was missing, so i had to resort to a revert instead of fix :( sorry :( SVN revision: 81267
2012-12-18no need to search headers in builddirVincent Torri
SVN revision: 81258
2012-12-14ecore_audio: Add tests caseDaniel Willmann
The sounds used are in the public domain and were taken from freesound.org Signed-off-by: Daniel Willmann <d.willmann@samsung.com> SVN revision: 81004
2012-12-12efl: Fix building examples when coverage is enabledDaniel Willmann
When we compile with coverage CFLAGS we also need to link with -lcov Signed-off-by: Daniel Willmann <d.willmann@samsung.com> SVN revision: 80770
2012-12-07efl: baby steps to get sharing of options between evas and ecore-evas.Gustavo Sverzut Barbieri
SVN revision: 80482
2012-12-06efl: let Ecore_EVas_Extn link with Ecore_Ipc as needed.Cedric BAIL
I think some people earned a borker badge here :-) SVN revision: 80293
2012-12-05ecore_evas: Make the engines loadable modulesFlavio Vinicius Alvares Ceolin
Implementing support for loadables modules. It makes the engines been loaded when they are needed. It not breakes the api, so each engine still has its own api. The implementation basically is: * Functions that creates Ecore_Evas, for example ecore_evas_software_x11_new, request to load its module and then get the module's function to create the Ecore_Evas. * The other functions such as \(.*\)_window_get from the Ecore_Evas its interface and then call the appropriate method. * As there is no unified interface to communicate with the engines (not break api problem), all interfaces were declared in ecore_evas_private.h * Now the data necessary for each module is not declared in the Ecore_Evas_Engine structure, instead of this, the struct has a void pointer that is used by the modules. * In this first moment engines as software_x11 and gl_x11 were put together in the same module, but obviously exporting all the things necessary. SVN revision: 80280
2012-12-05efl/ecore_evas: move deprecated functions to separate file, mark them.Gustavo Sverzut Barbieri
mark every deprecated function with EINA_DEPRECATED. move them to a separate file so we can easily delete them in future. SVN revision: 80253
2012-12-05directfb says bye...Gustavo Sverzut Barbieri
After agreement in the mail list, core developers agree to remove this engine that was not being supported for a long time. Given that most operations Evas uses are not accelerated in DirectFB, or at least hardware that exclusively supports DirectFB, it's better for those people to just use Evas/Ecore software (buffer) rendering and expose DirectFB's framebuffer as destination surface. SVN revision: 80232
2012-12-04merge: eio + fix compilation on windows + minor fixes + po filesVincent Torri
don't move eio to IN-EFL right now SVN revision: 80180
2012-12-03efl: enable back Ecore_Evas build after merge.Cedric BAIL
SVN revision: 80037
2012-12-02merge: add escape ecore, fix several bugsVincent Torri
SVN revision: 79995