Evas has an optional mechanism to do asynchronous preloading of
images. This mechanism is optional, and in commit
b6d92bf415 ("libevas: async image
preload support needs threads support in toolchain"), Peter made sure
to disable the asychronous preloading when no thread support was
available.
Unfortunately, it seems like disabling the asynchronous loading is
rarely used, and it in facts fails to build: a member of structure is
not present when asynchronous preloading is disabled, but the code
continues to use it.
Since the fix is not obvious, and all this mechanism seems to have
changed completely in EFL 1.8.x, and we probably don't care much about
EFL without threads, this commit adds a dependency of libevas on
thread support. Consequently, it also reverts commit
b6d92bf415 which is no longer necessary.
Of course, this commit propagates this additional dependency to the
reverse dependencies of libevas.
Fixes:
http://autobuild.buildroot.org/results/6de/6de90018a9eeb9c495d15046a8b3270eb95a5550//http://autobuild.buildroot.org/results/693/693df99db4ab357b48d427be3a72f6d64dd53065//
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In the Config.in file of package foo, it often happens that there are other
symbols besides BR2_PACKAGE_FOO. Typically, these symbols only make sense
when foo itself is enabled. There are two ways to express this: with
depends on BR2_PACKAGE_FOO
in each extra symbol, or with
if BR2_PACKAGE_FOO
...
endif
around the entire set of extra symbols.
The if/endif approach avoids the repetition of 'depends on' statements on
multiple symbols, so this is clearly preferred. But even when there is only
one extra symbol, if/endif is a more logical choice:
- it is future-proof for when extra symbols are added
- it allows to have just one strategy instead of two (less confusion)
This patch modifies the Config.in files accordingly.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
