Summary:
with autotools, EFL_BUILD was passed to the preprocessor for libraries and binaries, which was wrong. Only libraries must have EFL_BUILD defined. See T7797 for an explanation
This also fix EAPI in Ecore_Getopt.g and Efl_UI.h
Also note that all the wayland and drm Makefile's have not been touched
Test Plan: compilation
Reviewers: raster, zmike, cedric
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8602
Summary:
* some variables were defined, only when fork() was available
* since Eina.h is included unconditionally, add Eina path in Makefile_Evil.am
Test Plan: compilation
Reviewers: zmike, cedric, raster, devilhorns
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl_build
Differential Revision: https://phab.enlightenment.org/D8586
for some reason, a few projects changed this from the expected value of
abs_top_builddir for their test suites, breaking the usage of this define
within those tests
fix T6812
Reviewed-by: Stefan Schmidt <stefan@osg.samsung.com>
Test Plan: run on XP
Reviewers: jpeg, cedric, ajwillia.ms
Reviewed By: ajwillia.ms
Subscribers: ajwillia.ms
Differential Revision: https://phab.enlightenment.org/D5245
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.
Summary:
setlocale() called itself because it was defined as a #define
so remove this #define from evil_locale.h and move it in another header file
To avoid future problem, move similar defines to this header file
Also clean all the header file mess in Evil
Reviewers: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D3409
Add some internal dependencies when building Evil stuff:
The two binaries test_evil and evil_suite need libdl and libevil.
This should fix "make -j8"
Tested with using mingw64 cross compilation
This should reduce the code size of evil and reduce maintainance as
mingw does now take care of it.
Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
This reverts commit 0f0165e253.
Reverting my whole try to make the mingw build work with make -j6
on jenkins.
People told me that other people said that parallel build was
already working fine. Thats not what I see, but I could not care
less. If some folks leave the community but still want to preserve
ownership about specific parts I'm not in the mood for any such
politics.
Looks like USE_EVIL_INTERNEL_LIBS does only contains libevil itself.
For the test programs we still need the evil specific libdl for linking.
Lets hope this is the last parallel make fix for evil.
- Pass EVIL_CFLAGS to C++ compiled files (needed for -DEF_EVIL_BUILD)
- Some warning flags should not be passed to C++ compiler, so put them in another variable
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
Carefully compared 'svn export' and 'make dist' results and couple of
files were missing.
Changes:
* Makefile.am: removed all .pc from EXTRA_DIST, we shouldn't
distribute them here as they will contain ./configure data such as
install location.
* src/Makefile.am: moved all if-endif to files, otherwise EXTRA_DIST
won't work properly. We must EXTRA_DIST outside of the if-endif
block.
* static_libs/liblinebreak: removed couple of unused files.
SVN revision: 82241
- 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
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
When creating the rules to build, we can't declare the lib dependencies in
LDADD/LIBADD using $(top_builddir)/libbla.la because automake doesn't know this
is related to the libbla_la rule.
Please check if evil works, too. Since I don't run evil code, it's untested.
SVN revision: 78800
Please check.
note1: Only lib and bin for now, but should be extended to other stuff
note2: distcheck does not work because eo_suite is failing.
SVN revision: 78758
Vincent Torri
Mike Blumenkrantz
Andy Williams
Stefan Schmidt
Cedric Bail
Vincent Torri
Jean-Philippe Andre
Cedric Bail
Stefan Schmidt
Carsten Haitzler
Cedric Bail
Gustavo Sverzut Barbieri
Lucas De Marchi