sneaky hidden m4 rule to ADD -release to shared lib names IF profile
!= dev profile. come on! why do that? seriously. this snuck in and was
undetected because i recompiled things against efl and thus things
linked against the new releasename libs. this requires an efl 1.8.1.
argh!
Summary:
* efl.m4: add support for xterm-256color and fix display for the bsd echo. Fix autotools issue (present on Ubuntu also, but better handled).
* doc/Makefile.am: bsd echo may not handle -n option in sh
Reviewers: cedric
CC: cedric, seoz
Differential Revision: https://phab.enlightenment.org/D329
Linking to Pthread seems to be highly not portable. Look at lock.m4
macro if you want to understand the hell it is ! By following it
closely we should now have better portability than the 1.7.x release.
And of course than our alpha...
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.
Stumbled over it while trying to give configure a working edje_cc
when doing cross-compile. The path was picked up but never set as
the Makefile_Edje_Helper.am guarded it with HAVE_EDJE_CC which we
never successfully assigned due to this typo.
Thanks goes to Daniel for another round of pair-bug-spotting.
Just use the lib/name/libname.la as libtool should be responsible to
emit dependencies to compiler when it evaluates.
This should reduce over-linking, also reducing the compile lines in
our verbose builds ;-)
NOTE: this seems to work on Fedora 18 (which also bitch about DSO), so
hopefully works on Debian and Ubuntu (and elsewhere).
Please revert if breaks builds!
SVN revision: 83105
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
Many thanks to billiob that was persistent enough to make me look at
it while I was calling it "impossible". That stupid variable was being
used in ecore_check_module.m4 :-(
SVN revision: 82999
linker (ld) is that kind of tool that argument order matters, if you
-Wl,--as-needed, it will be worth just for libraries following
it. Then we need to use EFL_LDFLAGS before everything else, otherwise
it end being useless.
SVN revision: 82991
EFL_ADD_FEATURE(PKG, NAME, [VALUE]) will do an amazing work to produce
colored output in a standard way.
if value == yes, it's green and shows "+name"
if value == no, it's red and shows "-name"
else it shows cyan and shows "name=value"
if not provided, will use ${have_name:-${want_name}}
SVN revision: 82976
when I fixed eina's dependency on -lpthread I used all the libraries
eina links to. But we should just do with -lpthread as it's a public
dependency... that was in eina.pc.in and I missed.
Now we have EFL_ADD_PUBLIC_LIBS() that will register for
requirements_public_libs_name and use internally when eina is used.
This should also fix the problem by Arvind with gcrypt.
SVN revision: 82942
Seems AC_PATH_GENERIC() wasn't present somewhere, then I'm adding the
AM_PATH_LIBGCRYPT() provided by libcrypt (I need to include it in m4/
otherwise it will fail for people doing ./autogen.sh without libgcrypt
installed).
It works on my machine, but `libgcrypt-config --libs` output is just
"-lgcrypt -lgpg-error", including no -L.
SVN revision: 82939
some libraries will need to pull more than its own .so, for example
Eina.h includes eina_lock.h that includes eina_inline_lock_posix.x
that will use pthread calls directly from user code.
This was already listed in eina.pc, but not being present in
USE_EINA_LIBS.
SVN revision: 82909