the previous method of forcing this to be enabled for dist builds caused
breaks when the original configure disabled examples, as the little-known
DISTCHECK_CONFIGURE_FLAGS variable would need to also be set to disable
examples even though the user would think they were disabled based on configure
output
this would previously break if:
* cxx bindings were disabled
* elua was disabled
* base configure disabled examples and dist build disabled examples
* base configure disabled examples and dist build enabled examples
it still breaks if:
* base configure disables examples and dist build enables examples
This check for drmModeAtomicCommit is no longer necessary as we have
moved to using static_libs/libdrm during compile time.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
Well, the build is broken again on BSD and Windows.
efl_debugd is full of lots lovely Linuxisms. Just
don't compile.
This unbreaks the build for FreeBSD and others.
Reviewers: cedric, raster, jpeg
Reviewed By: jpeg
Subscribers: JackDanielZ, jpeg
Differential Revision: https://phab.enlightenment.org/D4946
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Changing ck_assert_ptr_nonnull() to ck_assert_ptr_ne() in order to
require "only" check >= 0.9.10. ck_assert_ptr_nonnull() was
introduced in 0.11.0. ck_assert_ptr_ne() is already used a lot
in the test suite so a recent version of check is required.
For this one I feel like I earned an archaeologist medal. :-)
This is related to the commit raster made in aa92cddb to accommodate for older
freetype version. The TT_INTERPRETER_VERSION_35 define was actually introduced
in the release 2.5.0 which was released in June 2013 which means it had almost
4 years to get picked up. I would consider this safe to be a minimum dependency
for current efl versions.
The trick here is that the release version does not match the library version
spit out by pkg-config. 16.2.10 equals the freetype 2.5.0.1 release in this case.
Better make a note about it in configure for the next poor soul trying to
understand this.
Thanks again to llelectronics for reporting this.
Fix T5437
@fix
This releases offers the gnutls_certificate_set_x509_trust_dir() API we use in
ecore_con. This gnutls version was release in July 2014 which gave it enough
time to be picked up by distributions.
Thanks a lot to llelectronics for reporting and tracking down the problem.
ref T5437
@fix
We have a report where the use of epoll breaks such systems. Disabling it for
now to make them work again. A deeper analysis is underway to understand this
better and maybe have epoll support later.
Not sure _ecore_fd_valid() is all that useful anymore, as the
commit that introduced it said it would be removed "before release"
a long time ago - it's a debug assist that probably doesn't need
to be in release builds.
(I'm counting syscalls on rpi3 - still, calling this an optimization
seems like a bit of a stretch.)
This reverts commit 25792d6416.
100 patches later the build output is still noisy with all these warnings.
I'm happy to see this warnings added to the default CFLAGS once the current
warnings have been dealt with.
Enable this warning in the local CFLAGS, get the current warnings fixed,
add it to the efl default flags to make the warning prominent for newly added
code.
Windows time_t is not a long, but long-long, then stick with int64_t
so it works everywhere (converts to time_t internally).
And there is no gmtime_r(), then use the gmtime() if not detected.
Since connman is specific to linux, on other platforms just compile a
dummy "none" backend that will always report online and no other
details. This will be used in Windows, MacOS and other platforms that
still lack a proper backend.
The compile-time infrastructure also allows for networkmanager to be
added with ease, simply copy "efl_net*-none.c" or "efl_net*-connman.c"
to be a starting point and then add its specifics, adapting
configure.ac and Makefile_Ecore_Con.am
This reverts commit dc7806e685.
NO. python does it out6 of the box by default. fix the error if you
have one and stop just "turning off the noise". the point of
having this is so that a REAL "why" can be provided by a user by
putting it through eina_btlog and you can see HOW the error happened
at least as a backtrace. turning it off "unless you sety environment
vars" is STUPID. especially for users of e who will likely be unable
to do this a they jusr use a display manager to launch e and cant just
"change environment vars" because they dont know how. you have just
made things worse for getting information fromt he people LEAST
capable of providing information which is where we need automated ways
of doing this "the most".
i use this backtrace all the time. every week or so i identify an
issue just by this built in trace so i know HOW we called that func
because the err complaint was utterly useless as it didnt tell me the
caller etc. which i needed to know "why". this also solves a valid
complain that if you are developibng with efl and e.g. use a legacy
func and pass in an invalid ob you need to know what CALLED the legacy
func. often the issue is several levels up. its the silent masses who
appreciate the feature and use it or then DONT complain. this allows
them to know what the SOURCE of the error is and notjust where it ends
up and this should be done by default out of the box regardless of it
being long because providing more informations is always better than
less. do you propose that kernel oopses should cease dumping all
registers and half a screen worth of junk because "well just set a
kernel boot param to turn it on next time". no. go propose that python
turn off their backtraces by default unless you set and env var. get
these groups to agree to do this, then i'll believe you that this is
TRULYU annoying and not useful and should be off.
you do this just because a few peolpe complain about an error happening
that "SHOULD NOT BE THERE". then FIX THE ERROR. the bt if provided should
nicely provde complete info on how you got there. just making the
error a 1 liner (and those lines are super long and for me 90% of the
time wrap 2 or 3 lines in a terminal) is just sticking your head in
the sand. if its not an error then dont use an eina ERROR use debug or
warn or something else...
User get bitten with this more than they benefit from it. Every use of Eina_Log
will trigger backtrace which clutter the output, confuse and scare users when
they are not suffering anything serious. It is also very trivial for user to turn
it on selectively with EINA_LOG_BACKTRACE when reporting a bug. So let's fallback
to a saner approach. The alternate logical solution would be for application to
just give up on Eina_Log, which is not really acceptable.