Summary:
2 threads run 'eo2_do(o, a(), b());'
- A goes first, creates an object, enters 'eo2_do(o, a(), b());'
in a() call, it blocks, releases B and waits for it.
- B when released, creates an object, enters 'eo2_do(o, a(), b());'
in a() call, it joins and releases A, then blocks.
- A returns from a(); and enters b() using current call stack frame,
which is the one pushed by B! then pop the frame and releases B.
- B does as above using the stack pushed by A!
Hmm, I forgot to add some .eo files to the EXTRA_DIST so they have not been
added inside the archive.
Eolian couldn't generate C files because of these missing files.
Summary: This feature replaces Eo pointers with ids to prevent bad usage
or reuse of these pointers. It doesn't change API.
The mechanism uses tables storing the real pointers to the objects.
See the src/lib/eo/eo_ptr_indirection.c file for more details on the
mechanism.
Test can only be build if they are enable. Moving them inside the if
so we don't get annoying error when make check is run without tests
being turned on.
This was stupid from the start, but now it casuse even more issues.
We'll have to just add a configure option to it when the time comes.
SVN revision: 82989
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
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
- 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