Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[Jérémy Zurcher]

Hi,
I've taken care of some, maybe all, of the observations :

https://git.enlightenment.org/core/efl.git/tree/mtests.sh?h=devs/jeyzu/mtests
https://git.enlightenment.org/core/efl.git/tree/src/lib/eina/tests?h=devs/jeyzu/mtests
https://git.enlightenment.org/core/efl.git/tree/src/tests/test_macros.h?h=devs/jeyzu/mtests

colorized : http://cgit.asynk.ch/bin/tree/mtests.sh


p.s.
  sorry Raster for the noise,
  I just realized that I was answering to you instead of the ML :|


On Saturday 17 December 2016  11:55, Jérémy Zurcher wrote :
> 
> 
> Hi,
> I wrote a quick and dirty POC ...
> comments welcome
> 
> <<<
> #! /bin/sh
> 
> SRC_D=src
> BUILD_D=src
> CONFIG_SH=config.sh
> INIT_C=init.c
> SHUTDOWN_C=shutdown.c
> C_FILE=/tmp/__efl_test.c
> O_FILE=/tmp/__efl_test.o
> DEBUG=0
> 
> SCRIPT_DIR=${0%/*}
> SCRIPT_FILE=${0##*/}
> 
> CC=${CC:-"clang"}
> LD=""
> INCLUDE=""
> 
> function fatal {
>echo "FATAL $1"
>exit 1
> }
> 
> while [ $# -ge 1 ]; do
> case "$1" in
> -s*|--src*)
> shift
> [ $# -lt 1 ] && fatal "option -s is missing directory argument"
> SRC_D=$1
> shift
> ;;
> -b*|--build*)
> shift
> [ $# -lt 1 ] && fatal "option -b is missing directory argument"
> BUILD_D=$1
> shift
> ;;
> 
> -h|--help)
> echo "Usage:  $SCRIPT_FILE [options]"
> echo
> echo "Options:"
> echo "-s, --src directoryDirectory to search tests into"
> echo "-b, --build directory  Directory to search built files 
> into"
> echo "-h, --help This message."
> exit 0
> ;;
> 
> *)
> break
> esac
> done
> 
> SRC_D=$(readlink -f $SRC_D)
> BUILD_D=$(readlink -f $BUILD_D)
> 
> [ -d "$SRC_D" -a -r "$SRC_D" ] || fatal "$SRC_D is not a valid directory"
> [ -d "$BUILD_D" -a -r "$BUILD_D" ] || fatal "$BUILD_D is not a valid 
> directory"
> 
> function load_cfg {
>unset LDS
>unset INCLUDES
>LDF=""
>LDP=""
>INCLUDE="-I .."
>if [ -f $CONFIG_SH -a -r $CONFIG_SH ]
>then
>   echo "load $CONFIG_SH"
>   source ./$CONFIG_SH
>   for include in $INCLUDES
>   do
>  F=$(find $SRC_D -name $include)
>  if [ -z "$F" ]
>  then
> F=$(find $BUILD_D -name $include)
> [ ! -z "$F" ] || fatal "can't find $include in $SRC_D or $BUILD_D"
>  fi
>  INCLUDE="$INCLUDE -I ${F%/*}"
>   done
>   for ld in $LDS
>   do
>  F=$(find $BUILD_D -name $ld)
>  [ ! -z "$F" ] || fatal "can't find $ld in $BUILD_D"
>  F=$(readlink -f $F)
>  LDP="$LDP -L ${F%/*}"
>  lib=${F##*/lib}
>  lib=${lib%.so*}
>  LDF="$LDF -l$lib"
>   done
>fi
> }
> 
> echo "search for tests into $SRC_D"
> for dir in $(find $SRC_D -type d -name tests)
> do
>echo "  enter $dir"
>pushd $dir > /dev/null || fatal "cannot enter $dir"
>[ -f $INIT_C -a -r $INIT_C ] || fatal "missing mandatory file $INIT_C"
>[ -f $SHUTDOWN_C -a -r $SHUTDOWN_C ] || fatal "missing mandatory file 
> $SHUTDOWN_C"
>load_cfg
>for test_c in $(ls -1 test_*.c)
>do
>   echo -n "compile and run $test_c"
>   cat $INIT_C $test_c $SHUTDOWN_C > $C_FILE
>   CMD="$CC $INCLUDE $LDP $LDF -o $C_FILE.o $O_FILE"
>   [ $DEBUG -eq 1 ] && echo "$CMD"
>   $CMD || fatal "compilation failed"
>   $O_FILE.o && echo " PASS" || fatal "test run failed"
>done
>echo "  leave"
>popd > /dev/null
> done
> echo "done"
> <<<
> 
> 
> this is what I've got in src/lib/eina/tests
> 
> jeyzu@bigdaddy: tests (master) $ cat config.sh
> INCLUDES="eina_config.h Eina.h Efl_Config.h"
> LDS="libeina.so"
> 
> jeyzu@bigdaddy: tests (master) $ cat init.c
> #include 
> 
> #define FAIL_IF(_x) if ((_x)) { fprintf(stderr, "fail\n"); exit(1); }
> 
> int main(int argc, char *argv[])
> {
>eina_init();
> 
> jeyzu@bigdaddy: tests (master) $ cat shutdown.c
>   eina_shutdown();
>   return 0;
> }
> 
> jeyzu@bigdaddy: tests (master) $ cat test_list_append.c
> Eina_List *list = NULL;
> list = eina_list_append(list, (void *)123L);
> FAIL_IF(eina_list_data_find_list(list, (void *)123L) != list);
> 
> 
> run from topdir
> jeyzu@bigdaddy: efl (master) $ ./tests.sh -s src/lib/eina -b build
> search for tests into /home/jeyzu/usr/git/efl/core/efl/src/lib/eina
>   enter /home/jeyzu/usr/git/efl/core/efl/src/lib/eina/tests
> load config.sh
> compile and run test_list_append.c PASS
>   leave
> done
> 
> 
> --- Hell'O from Yverdoom
> 
> Jérémy (jeyzu)
--- Hell'O from Yverdoom

Jérémy (jeyzu)

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi 

Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[The Rasterman]

On Sat, 17 Dec 2016 11:55:38 +0100 Jérémy Zurcher  said:

yeah - this below is getitng close. i have to say i kind of agree with cedric
and ks that maybe instead of an init/shutdown we can have a "template.c"
perhaps like the below. this allows for test to declare callback funcs too as
long as FUNC is always there - consider it the main for a test... and macros.h
is just all our test macros for tests to use and main.c is the template that
sets up the test with includes, inits and calls FUNCCALL(); to do the test then
shuts down and exits cleanly (any failures should exit before here). we come up
with a new dir with a main.c in it per style/type of test that has a common
init/shutdown etc. scenario.


test_x.c:
FUNC {
  Eina_List *list = NULL;
  list = eina_list_append(list, (void *)123L);
  FAIL_IF(eina_list_data_find_list(list, (void *)123L) != list);
}


test_y.c:
FUNC {
  Eina_List *list = NULL;
  list = eina_list_prepend(list, (void *)123L);
  FAIL_IF(eina_list_data_find_list(list, (void *)123L) != list);
}


macros.h:
#define FAIL_IF(_x) if ((_x)) { fprintf(stderr, "fail\n"); exit(1); }
#define STR(x) #x


main.c:
#include "macros.h"
#include "eina_config.h"
#include "Eina.h"
#include "Efl_Config.h"

#include STR(TESTFILE)

int main(int argc, char **argv) {
  eina_init();

  FUNCCALL();

  eina_shutdown();
  return 0;
}

then to build the test:
#/bin/sh -e
TESTSRCDIR=/path/to/tests
TESTBINDIR=/tmp
for TEST in `/bin/ls $SRCDIR/test_*.c | sort`; do
  TEST=`basename $TEST .c`
  $CC $TESTSRCDIR/main.c \
   -o $TESTSRCDIR/$TEST \
   -DTESTFILE=$TEST.c \
   -DFUNC='static void '$TEST'(void)' \
   -DFUNCCALL=$TEST \
   -I/somthing -I/something2 \
   -L/link/dir -lsomething -lsomething2 ...
  echo "TESTING $TEST.c ... "
  if $TESTBINDIR/$TEST; then
echo OK;
  else
echo FAIL
exit 42 # should we exit on first fail or keep going?
  fi
fi


i like that you handled build_dir stuff etc. too (out of tree builds) and so
on. so definitely keep a lot of that and maybe something like above?

> 
> 
> Hi,
> I wrote a quick and dirty POC ...
> comments welcome
> 
> <<<
> #! /bin/sh
> 
> SRC_D=src
> BUILD_D=src
> CONFIG_SH=config.sh
> INIT_C=init.c
> SHUTDOWN_C=shutdown.c
> C_FILE=/tmp/__efl_test.c
> O_FILE=/tmp/__efl_test.o
> DEBUG=0
> 
> SCRIPT_DIR=${0%/*}
> SCRIPT_FILE=${0##*/}
> 
> CC=${CC:-"clang"}
> LD=""
> INCLUDE=""
> 
> function fatal {
>echo "FATAL $1"
>exit 1
> }
> 
> while [ $# -ge 1 ]; do
> case "$1" in
> -s*|--src*)
> shift
> [ $# -lt 1 ] && fatal "option -s is missing directory argument"
> SRC_D=$1
> shift
> ;;
> -b*|--build*)
> shift
> [ $# -lt 1 ] && fatal "option -b is missing directory argument"
> BUILD_D=$1
> shift
> ;;
> 
> -h|--help)
> echo "Usage:  $SCRIPT_FILE [options]"
> echo
> echo "Options:"
> echo "-s, --src directoryDirectory to search tests into"
> echo "-b, --build directory  Directory to search built files
> into" echo "-h, --help This message."
> exit 0
> ;;
> 
> *)
> break
> esac
> done
> 
> SRC_D=$(readlink -f $SRC_D)
> BUILD_D=$(readlink -f $BUILD_D)
> 
> [ -d "$SRC_D" -a -r "$SRC_D" ] || fatal "$SRC_D is not a valid directory"
> [ -d "$BUILD_D" -a -r "$BUILD_D" ] || fatal "$BUILD_D is not a valid
> directory"
> 
> function load_cfg {
>unset LDS
>unset INCLUDES
>LDF=""
>LDP=""
>INCLUDE="-I .."
>if [ -f $CONFIG_SH -a -r $CONFIG_SH ]
>then
>   echo "load $CONFIG_SH"
>   source ./$CONFIG_SH
>   for include in $INCLUDES
>   do
>  F=$(find $SRC_D -name $include)
>  if [ -z "$F" ]
>  then
> F=$(find $BUILD_D -name $include)
> [ ! -z "$F" ] || fatal "can't find $include in $SRC_D or $BUILD_D"
>  fi
>  INCLUDE="$INCLUDE -I ${F%/*}"
>   done
>   for ld in $LDS
>   do
>  F=$(find $BUILD_D -name $ld)
>  [ ! -z "$F" ] || fatal "can't find $ld in $BUILD_D"
>  F=$(readlink -f $F)
>  LDP="$LDP -L ${F%/*}"
>  lib=${F##*/lib}
>  lib=${lib%.so*}
>  LDF="$LDF -l$lib"
>   done
>fi
> }
> 
> echo "search for tests into $SRC_D"
> for dir in $(find $SRC_D -type d -name tests)
> do
>echo "  enter $dir"
>pushd $dir > /dev/null || fatal "cannot enter $dir"
>[ -f $INIT_C -a -r $INIT_C ] || fatal "missing mandatory file $INIT_C"
>[ -f $SHUTDOWN_C -a -r $SHUTDOWN_C ] || fatal "missing mandatory file
> $SHUTDOWN_C" load_cfg
>for test_c in $(ls -1 test_*.c)
>do
>   echo -n "compile and run $test_c"
>   cat $INIT_C $test_c $SHUTDOWN_C > $C_FILE
>   CMD="$CC $INCLUDE $LDP $LDF -o $C_FILE.o $O_FILE"
>   [ $DEBUG -eq 1 ] 

Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[Gustavo Sverzut Barbieri]

I like what Jeremy did based on Raster's suggestion.

My 2 cents on that is to have the files to contain the function
signatures because most editors (at least Emacs) will think stuff are
in global scope and indent weirdly.

they can be a function for real or just a placeholder macro such as
TEST_FUNC(), then we add braces around.

Also, for simple tests one function per file will do, but spawning
callbacks to their own files will become a PITA for most cases,
particularly if you need to pass some context structure.

do we want to ditch the check.h usage? Or just increment that? Like we
generate check-compatible code and use their macros?

but it's in the right direction I'd say...




On Sun, Dec 18, 2016 at 2:31 AM, Cedric BAIL  wrote:
> On Sat, Dec 17, 2016 at 2:55 AM, Jérémy Zurcher  wrote:
>> 
>> I wrote a quick and dirty POC ...
>> comments welcome
>
> I was myself thinking of doing some macro magic. I would introduce a
> EFL_START_TEST and EFL_END_TEST macro that will have two
> implementation. One will initialize/shutdown for that tests suite
> properly the needed dependency and the other implementation will just
> add the case without executing the code in between.
>
> Along with refactoring the main that is mostly a copy and paste in
> most tests suite we have (except for eo) and providing a proper debug
> mode that would restart that same binary under valgrind (A nice bonus
> would be to automatically attach gdb in case of error), I think it
> shouldn't be to much work to get things slightly better. The issue
> will remain that most tests need some cleanup as described by Gustavo
> and that's more time consuming.
>
> I will try to prototype something quickly next week so that everyone
> can get an idea.
>
> Cheers,
> --
> Cedric BAIL
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[Cedric BAIL]

On Sat, Dec 17, 2016 at 2:55 AM, Jérémy Zurcher  wrote:
> 
> I wrote a quick and dirty POC ...
> comments welcome

I was myself thinking of doing some macro magic. I would introduce a
EFL_START_TEST and EFL_END_TEST macro that will have two
implementation. One will initialize/shutdown for that tests suite
properly the needed dependency and the other implementation will just
add the case without executing the code in between.

Along with refactoring the main that is mostly a copy and paste in
most tests suite we have (except for eo) and providing a proper debug
mode that would restart that same binary under valgrind (A nice bonus
would be to automatically attach gdb in case of error), I think it
shouldn't be to much work to get things slightly better. The issue
will remain that most tests need some cleanup as described by Gustavo
and that's more time consuming.

I will try to prototype something quickly next week so that everyone
can get an idea.

Cheers,
-- 
Cedric BAIL

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[Jérémy Zurcher]

I had a some fun with this moronic bash driven test suite

http://cgit.asynk.ch/bin/tree/mtests.sh

--- Hell'O from Yverdoom

Jérémy (jeyzu)

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[Jérémy Zurcher]

Hi,
I wrote a quick and dirty POC ...
comments welcome

<<<
#! /bin/sh

SRC_D=src
BUILD_D=src
CONFIG_SH=config.sh
INIT_C=init.c
SHUTDOWN_C=shutdown.c
C_FILE=/tmp/__efl_test.c
O_FILE=/tmp/__efl_test.o
DEBUG=0

SCRIPT_DIR=${0%/*}
SCRIPT_FILE=${0##*/}

CC=${CC:-"clang"}
LD=""
INCLUDE=""

function fatal {
   echo "FATAL $1"
   exit 1
}

while [ $# -ge 1 ]; do
case "$1" in
-s*|--src*)
shift
[ $# -lt 1 ] && fatal "option -s is missing directory argument"
SRC_D=$1
shift
;;
-b*|--build*)
shift
[ $# -lt 1 ] && fatal "option -b is missing directory argument"
BUILD_D=$1
shift
;;

-h|--help)
echo "Usage:  $SCRIPT_FILE [options]"
echo
echo "Options:"
echo "-s, --src directoryDirectory to search tests into"
echo "-b, --build directory  Directory to search built files 
into"
echo "-h, --help This message."
exit 0
;;

*)
break
esac
done

SRC_D=$(readlink -f $SRC_D)
BUILD_D=$(readlink -f $BUILD_D)

[ -d "$SRC_D" -a -r "$SRC_D" ] || fatal "$SRC_D is not a valid directory"
[ -d "$BUILD_D" -a -r "$BUILD_D" ] || fatal "$BUILD_D is not a valid directory"

function load_cfg {
   unset LDS
   unset INCLUDES
   LDF=""
   LDP=""
   INCLUDE="-I .."
   if [ -f $CONFIG_SH -a -r $CONFIG_SH ]
   then
  echo "load $CONFIG_SH"
  source ./$CONFIG_SH
  for include in $INCLUDES
  do
 F=$(find $SRC_D -name $include)
 if [ -z "$F" ]
 then
F=$(find $BUILD_D -name $include)
[ ! -z "$F" ] || fatal "can't find $include in $SRC_D or $BUILD_D"
 fi
 INCLUDE="$INCLUDE -I ${F%/*}"
  done
  for ld in $LDS
  do
 F=$(find $BUILD_D -name $ld)
 [ ! -z "$F" ] || fatal "can't find $ld in $BUILD_D"
 F=$(readlink -f $F)
 LDP="$LDP -L ${F%/*}"
 lib=${F##*/lib}
 lib=${lib%.so*}
 LDF="$LDF -l$lib"
  done
   fi
}

echo "search for tests into $SRC_D"
for dir in $(find $SRC_D -type d -name tests)
do
   echo "  enter $dir"
   pushd $dir > /dev/null || fatal "cannot enter $dir"
   [ -f $INIT_C -a -r $INIT_C ] || fatal "missing mandatory file $INIT_C"
   [ -f $SHUTDOWN_C -a -r $SHUTDOWN_C ] || fatal "missing mandatory file 
$SHUTDOWN_C"
   load_cfg
   for test_c in $(ls -1 test_*.c)
   do
  echo -n "compile and run $test_c"
  cat $INIT_C $test_c $SHUTDOWN_C > $C_FILE
  CMD="$CC $INCLUDE $LDP $LDF -o $C_FILE.o $O_FILE"
  [ $DEBUG -eq 1 ] && echo "$CMD"
  $CMD || fatal "compilation failed"
  $O_FILE.o && echo " PASS" || fatal "test run failed"
   done
   echo "  leave"
   popd > /dev/null
done
echo "done"
<<<


this is what I've got in src/lib/eina/tests

jeyzu@bigdaddy: tests (master) $ cat config.sh
INCLUDES="eina_config.h Eina.h Efl_Config.h"
LDS="libeina.so"

jeyzu@bigdaddy: tests (master) $ cat init.c
#include 

#define FAIL_IF(_x) if ((_x)) { fprintf(stderr, "fail\n"); exit(1); }

int main(int argc, char *argv[])
{
   eina_init();

jeyzu@bigdaddy: tests (master) $ cat shutdown.c
  eina_shutdown();
  return 0;
}

jeyzu@bigdaddy: tests (master) $ cat test_list_append.c
Eina_List *list = NULL;
list = eina_list_append(list, (void *)123L);
FAIL_IF(eina_list_data_find_list(list, (void *)123L) != list);


run from topdir
jeyzu@bigdaddy: efl (master) $ ./tests.sh -s src/lib/eina -b build
search for tests into /home/jeyzu/usr/git/efl/core/efl/src/lib/eina
  enter /home/jeyzu/usr/git/efl/core/efl/src/lib/eina/tests
load config.sh
compile and run test_list_append.c PASS
  leave
done


--- Hell'O from Yverdoom

Jérémy (jeyzu)

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[The Rasterman]

On Fri, 16 Dec 2016 13:19:51 -0800 Cedric BAIL  said:

> On Fri, Dec 16, 2016 at 2:43 AM, Gustavo Sverzut Barbieri
>  wrote:
> > On Fri, Dec 16, 2016 at 7:54 AM, Stefan Schmidt 
> > wrote:
> >> On 13/12/16 16:32, Gustavo Sverzut Barbieri wrote:
> >>> On Tue, Dec 13, 2016 at 11:54 AM, Stefan Schmidt 
> >>> wrote:
>  On 13/12/16 14:09, Felipe Magno de Almeida wrote:
> > On Tue, Dec 13, 2016 at 8:28 AM, Stefan Schmidt
> >  wrote:
> 
> [snip]
> 
>  but a test that fails on a machine that doesn't
> > handle IPv6 seems fine to me as long as it is rare enough.
> 
>  We assume IPv6 now, we assume a working internet connection, we assume
>  udev for eeze testing, we assume a working dbus setup, in some cases we
>  assume a file system which supports extended attributes, etc...
> 
>  If it is complicated to run make check we will have even less people
>  running it. It should be the other way around. I guess I could look at
>  anybody here who contributed a few patches this year and see someone who
>  broke make check. If it is to complicated or fails for some reason
>  people will just stop using it.
> >>>
> >>> our test suite is unusable the way it is...
> >>
> >> While I agree that the test suite needs improvements calling it unusable
> >> is over the top.
> >
> > ok, so  improved... particularly for developers to run them... also
> > something that simplifies to write them, and how to do it properly.
> >
> > For instance, very few tests uses correct macros in check.h, like
> > ck_assert_int_eq(), that will highlight expected values and required
> > values, compared to failif(a == b). Some tests miss granularity, so
> > they do bunch of tests at once, missing the "unit test" aspect...  and
> > while we can manually select the test suite to run (calling it
> > directly), and sometimes the component (ie: ecore_con_suite -h to list
> > them), it would be very helpful to select individual functions to
> > test, particularly under development. And some helpers to debug
> > failing tests (I always need to check for CK_FORK=no and things like
> > that).
> 
> I agree with you on the missing granularity. Some tests are awful in
> that regard. Overall I like most of your point here, it is just so
> massive and our ressource are spread so thinly that it is not
> something anyone working on the core as time to work on. But this task
> are pretty simple and easy, they are quite an easy training to learn
> our API, environment and contribute their first patches. We could have
> a beginner/new comer section in our wiki for developers to know about
> this.
> 
> As for the helper, a simple shell script that set CK_RUN_CASE, CK_FORK
> and start the test suite under valgrind + gdb shouldn't be to hard I
> think. I personnaly always rely on CK_RUN_CASE + valgrind
> --trace-children and do not bother with gdb, but I can see its use.

i also dislike our test suite.

1. barrier of entry. simply it takes too much footwork to add a simple 1 or 2
line test, so what everyone ends up doing is making 1 tests case that is 20 or
50 lines testing lots of things to share the footwork across multiple tests
2. the forking thing check does by default is just a pain. i keep having to set
up CK_FORK=no
3. to then run under either gdb or valgrind i hunt the correct binary down in
tests/testname/.libs dir and run it.

what i'd love to see is something like:

a directory per "dependencies" (#includes and linking info) with some master
file that lists init and shutdown code for all test in that dir. it may be as
simple as #include  + eina_init/shutdown or may include a dozen efl
headers init a dozen efl libs, create a canvas/window with a default background
etc.

in this directory then every file named test_something.c can just be:

test_list_append.c:

  Eina_List *list = NULL;
  list = eina_list_append(list, (void *)123L);
  FAIL_IF(eina_list_data_find_list(list, (void *)123L) != list);

boilerplate-free. no need to edit a makefile.am. no need to declare a function
and then put it in prototypes and add it to a list of funcs for check to run...
we should have a script or something that just does this automatically. i'd
want 1 binary per test too. explicitly. if you need callbacks maybe have

test_list_append.cb.c:

  static void my_cb(void *data)
{
   // whatever
}

list all such funcs to that file and if it exists it'll be put above the test
that would be in main. the per-fir dependencies are wrapped around with the
includes at the top, a main function auto-generated and in that all init calls,
and then the test and then shutdown calls.

something like this would be awfully nicer than what we have.

> > what happens in most of the cases is that the suite is painful to deal
> > with so it's easier to write the "other required" bit that is the
> > example and test from 

Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[Cedric BAIL]

On Fri, Dec 16, 2016 at 2:43 AM, Gustavo Sverzut Barbieri
 wrote:
> On Fri, Dec 16, 2016 at 7:54 AM, Stefan Schmidt  
> wrote:
>> On 13/12/16 16:32, Gustavo Sverzut Barbieri wrote:
>>> On Tue, Dec 13, 2016 at 11:54 AM, Stefan Schmidt  
>>> wrote:
 On 13/12/16 14:09, Felipe Magno de Almeida wrote:
> On Tue, Dec 13, 2016 at 8:28 AM, Stefan Schmidt  
> wrote:

[snip]

 but a test that fails on a machine that doesn't
> handle IPv6 seems fine to me as long as it is rare enough.

 We assume IPv6 now, we assume a working internet connection, we assume
 udev for eeze testing, we assume a working dbus setup, in some cases we
 assume a file system which supports extended attributes, etc...

 If it is complicated to run make check we will have even less people
 running it. It should be the other way around. I guess I could look at
 anybody here who contributed a few patches this year and see someone who
 broke make check. If it is to complicated or fails for some reason
 people will just stop using it.
>>>
>>> our test suite is unusable the way it is...
>>
>> While I agree that the test suite needs improvements calling it unusable
>> is over the top.
>
> ok, so  improved... particularly for developers to run them... also
> something that simplifies to write them, and how to do it properly.
>
> For instance, very few tests uses correct macros in check.h, like
> ck_assert_int_eq(), that will highlight expected values and required
> values, compared to failif(a == b). Some tests miss granularity, so
> they do bunch of tests at once, missing the "unit test" aspect...  and
> while we can manually select the test suite to run (calling it
> directly), and sometimes the component (ie: ecore_con_suite -h to list
> them), it would be very helpful to select individual functions to
> test, particularly under development. And some helpers to debug
> failing tests (I always need to check for CK_FORK=no and things like
> that).

I agree with you on the missing granularity. Some tests are awful in
that regard. Overall I like most of your point here, it is just so
massive and our ressource are spread so thinly that it is not
something anyone working on the core as time to work on. But this task
are pretty simple and easy, they are quite an easy training to learn
our API, environment and contribute their first patches. We could have
a beginner/new comer section in our wiki for developers to know about
this.

As for the helper, a simple shell script that set CK_RUN_CASE, CK_FORK
and start the test suite under valgrind + gdb shouldn't be to hard I
think. I personnaly always rely on CK_RUN_CASE + valgrind
--trace-children and do not bother with gdb, but I can see its use.

> what happens in most of the cases is that the suite is painful to deal
> with so it's easier to write the "other required" bit that is the
> example and test from there, rather than do it from the test suite...
> which is what I did, and some guys follow the same pattern (or just
> commit to enlightenment an usage).
>
>>   really it lacks
>>> granularity, it takes lots of time and most of the time it looks like
>>> it failed since people forget to trap EINA_LOG to capture errors, then
>>> you get tons of error messages (although the test reports success,
>>> messages confuses users).
>>
>> In the normal run you see a green PASS or red FAILED. The eina_log
>> errors are only in the log file itself.
>
> still, this is for build bot or random users running the tests. Not to
> us, the developers... you're going to run the full test suite after
> each development step... becomes costly and painful :-/

I agree with Gustavo here I think. Having all our tests hidden behind
PASS/FAILED make it a problem to deal with when running make check as
you have to read somewhere else what is going on. Would be neat if
they where not directed to a file actually... but then we really
should be more careful with our printf/log !
-- 
Cedric BAIL

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[Jonathan Aquilina]

I am helping beber admin but given that there is no system documentation on how 
things are complexly setup I feel I am not much help to fix this issue.

Sent from my iPhone

> On 16 Dec 2016, at 11:43, Gustavo Sverzut Barbieri  wrote:
> 
>> On Fri, Dec 16, 2016 at 7:54 AM, Stefan Schmidt  
>> wrote:
>> Hello.
>> 
>>> On 13/12/16 16:32, Gustavo Sverzut Barbieri wrote:
 On Tue, Dec 13, 2016 at 11:54 AM, Stefan Schmidt  
 wrote:
 Hello.
 
> On 13/12/16 14:09, Felipe Magno de Almeida wrote:
>> On Tue, Dec 13, 2016 at 8:28 AM, Stefan Schmidt  
>> wrote:
>> Hello.
> 
> [snip]
> 
>> I fully agree (even have native IPv6 here) but we need to be defensive
>> what we expect to be available in our test suite.
> 
> Why? It is testing, I agree we should need to be defensive in the
> implementation and interfaces where EFL might run in stranger
> environments,
 
 If the implementation would handle this all gracefully the test would
 never had been a problem. :)
>>> 
>>> no no... the code gracefully handles that, but the test is explicit
>>> "resolve ::1 to ::1 and I expect it to work". The test itself should
>>> be conditional and I'm willing to do that, HOWEVER our test bots
>>> should have IPv6 so we check that code.
>>> 
>>> 
>>> 
 but a test that fails on a machine that doesn't
> handle IPv6 seems fine to me as long as it is rare enough.
 
 We assume IPv6 now, we assume a working internet connection, we assume
 udev for eeze testing, we assume a working dbus setup, in some cases we
 assume a file system which supports extended attributes, etc...
 
 If it is complicated to run make check we will have even less people
 running it. It should be the other way around. I guess I could look at
 anybody here who contributed a few patches this year and see someone who
 broke make check. If it is to complicated or fails for some reason
 people will just stop using it.
>>> 
>>> our test suite is unusable the way it is...
>> 
>> While I agree that the test suite needs improvements calling it unusable
>> is over the top.
> 
> ok, so  improved... particularly for developers to run them... also
> something that simplifies to write them, and how to do it properly.
> 
> For instance, very few tests uses correct macros in check.h, like
> ck_assert_int_eq(), that will highlight expected values and required
> values, compared to failif(a == b). Some tests miss granularity, so
> they do bunch of tests at once, missing the "unit test" aspect...  and
> while we can manually select the test suite to run (calling it
> directly), and sometimes the component (ie: ecore_con_suite -h to list
> them), it would be very helpful to select individual functions to
> test, particularly under development. And some helpers to debug
> failing tests (I always need to check for CK_FORK=no and things like
> that).
> 
> what happens in most of the cases is that the suite is painful to deal
> with so it's easier to write the "other required" bit that is the
> example and test from there, rather than do it from the test suite...
> which is what I did, and some guys follow the same pattern (or just
> commit to enlightenment an usage).
> 
> 
>>  really it lacks
>>> granularity, it takes lots of time and most of the time it looks like
>>> it failed since people forget to trap EINA_LOG to capture errors, then
>>> you get tons of error messages (although the test reports success,
>>> messages confuses users).
>> 
>> In the normal run you see a green PASS or red FAILED. The eina_log
>> errors are only in the log file itself.
> 
> still, this is for build bot or random users running the tests. Not to
> us, the developers... you're going to run the full test suite after
> each development step... becomes costly and painful :-/
> 
> 
>> What is the way to trap these
>> error messages that will come if we do test error cases? IIRC you did
>> eina_log initially so you surely have a good solution here. :)
> 
> see src/tests/ecore_con/ecore_con_test_efl_net_ip_address.c
> 
> but it was done in a similar way for other tests, you simply trap by
> providing your own print callback and checking if you got the message
> you expected.
> 
> and this is the kind of stuff that we could improve as well.. I had to
> find in the code other similar usages and redo it... but it's not that
> generic that can be used everywhere... so a better solution would be
> handy. as well as more "ck_assert*" macros for our stuff, like
> "ck_assert_eina_list_str_equal()",
> "ck_assert_eina_list_str_contains()", and things like that. Also ways
> to run the main loop with an automatic timeout, ecore_con_suite for
> failed tests were cumbersome to test as if you didn't get a result
> (ie: ecore_con_url test), then it would sit there forever... adding an
> ecore_timer_add() + 

Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[Gustavo Sverzut Barbieri]

On Fri, Dec 16, 2016 at 7:54 AM, Stefan Schmidt  wrote:
> Hello.
>
> On 13/12/16 16:32, Gustavo Sverzut Barbieri wrote:
>> On Tue, Dec 13, 2016 at 11:54 AM, Stefan Schmidt  
>> wrote:
>>> Hello.
>>>
>>> On 13/12/16 14:09, Felipe Magno de Almeida wrote:
 On Tue, Dec 13, 2016 at 8:28 AM, Stefan Schmidt  
 wrote:
> Hello.

 [snip]

> I fully agree (even have native IPv6 here) but we need to be defensive
> what we expect to be available in our test suite.

 Why? It is testing, I agree we should need to be defensive in the
 implementation and interfaces where EFL might run in stranger
 environments,
>>>
>>> If the implementation would handle this all gracefully the test would
>>> never had been a problem. :)
>>
>> no no... the code gracefully handles that, but the test is explicit
>> "resolve ::1 to ::1 and I expect it to work". The test itself should
>> be conditional and I'm willing to do that, HOWEVER our test bots
>> should have IPv6 so we check that code.
>>
>>
>>
>>> but a test that fails on a machine that doesn't
 handle IPv6 seems fine to me as long as it is rare enough.
>>>
>>> We assume IPv6 now, we assume a working internet connection, we assume
>>> udev for eeze testing, we assume a working dbus setup, in some cases we
>>> assume a file system which supports extended attributes, etc...
>>>
>>> If it is complicated to run make check we will have even less people
>>> running it. It should be the other way around. I guess I could look at
>>> anybody here who contributed a few patches this year and see someone who
>>> broke make check. If it is to complicated or fails for some reason
>>> people will just stop using it.
>>
>> our test suite is unusable the way it is...
>
> While I agree that the test suite needs improvements calling it unusable
> is over the top.

ok, so  improved... particularly for developers to run them... also
something that simplifies to write them, and how to do it properly.

For instance, very few tests uses correct macros in check.h, like
ck_assert_int_eq(), that will highlight expected values and required
values, compared to failif(a == b). Some tests miss granularity, so
they do bunch of tests at once, missing the "unit test" aspect...  and
while we can manually select the test suite to run (calling it
directly), and sometimes the component (ie: ecore_con_suite -h to list
them), it would be very helpful to select individual functions to
test, particularly under development. And some helpers to debug
failing tests (I always need to check for CK_FORK=no and things like
that).

what happens in most of the cases is that the suite is painful to deal
with so it's easier to write the "other required" bit that is the
example and test from there, rather than do it from the test suite...
which is what I did, and some guys follow the same pattern (or just
commit to enlightenment an usage).


>   really it lacks
>> granularity, it takes lots of time and most of the time it looks like
>> it failed since people forget to trap EINA_LOG to capture errors, then
>> you get tons of error messages (although the test reports success,
>> messages confuses users).
>
> In the normal run you see a green PASS or red FAILED. The eina_log
> errors are only in the log file itself.

still, this is for build bot or random users running the tests. Not to
us, the developers... you're going to run the full test suite after
each development step... becomes costly and painful :-/


> What is the way to trap these
> error messages that will come if we do test error cases? IIRC you did
> eina_log initially so you surely have a good solution here. :)

see src/tests/ecore_con/ecore_con_test_efl_net_ip_address.c

but it was done in a similar way for other tests, you simply trap by
providing your own print callback and checking if you got the message
you expected.

and this is the kind of stuff that we could improve as well.. I had to
find in the code other similar usages and redo it... but it's not that
generic that can be used everywhere... so a better solution would be
handy. as well as more "ck_assert*" macros for our stuff, like
"ck_assert_eina_list_str_equal()",
"ck_assert_eina_list_str_contains()", and things like that. Also ways
to run the main loop with an automatic timeout, ecore_con_suite for
failed tests were cumbersome to test as if you didn't get a result
(ie: ecore_con_url test), then it would sit there forever... adding an
ecore_timer_add() + ecore_main_loop_quit() would help, but this could
be automatic.


>> just  the time it takes to run it all is one of the reasons I don't
>> run them that frequently. :-/
>
> You know that you can run the suites individually. When doing ecore_con
> stuff for example you could ignore the suites like eina and ecore which
> take a lot time.

still, I was doing ip_address tests and ecore_con_url and
ecore_con_server tests took a painful amount of 

Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[Stefan Schmidt]

Hello.

On 13/12/16 16:32, Gustavo Sverzut Barbieri wrote:
> On Tue, Dec 13, 2016 at 11:54 AM, Stefan Schmidt  
> wrote:
>> Hello.
>>
>> On 13/12/16 14:09, Felipe Magno de Almeida wrote:
>>> On Tue, Dec 13, 2016 at 8:28 AM, Stefan Schmidt  
>>> wrote:
 Hello.
>>>
>>> [snip]
>>>
 I fully agree (even have native IPv6 here) but we need to be defensive
 what we expect to be available in our test suite.
>>>
>>> Why? It is testing, I agree we should need to be defensive in the
>>> implementation and interfaces where EFL might run in stranger
>>> environments,
>>
>> If the implementation would handle this all gracefully the test would
>> never had been a problem. :)
>
> no no... the code gracefully handles that, but the test is explicit
> "resolve ::1 to ::1 and I expect it to work". The test itself should
> be conditional and I'm willing to do that, HOWEVER our test bots
> should have IPv6 so we check that code.
>
>
>
>> but a test that fails on a machine that doesn't
>>> handle IPv6 seems fine to me as long as it is rare enough.
>>
>> We assume IPv6 now, we assume a working internet connection, we assume
>> udev for eeze testing, we assume a working dbus setup, in some cases we
>> assume a file system which supports extended attributes, etc...
>>
>> If it is complicated to run make check we will have even less people
>> running it. It should be the other way around. I guess I could look at
>> anybody here who contributed a few patches this year and see someone who
>> broke make check. If it is to complicated or fails for some reason
>> people will just stop using it.
>
> our test suite is unusable the way it is...

While I agree that the test suite needs improvements calling it unusable 
is over the top.

  really it lacks
> granularity, it takes lots of time and most of the time it looks like
> it failed since people forget to trap EINA_LOG to capture errors, then
> you get tons of error messages (although the test reports success,
> messages confuses users).

In the normal run you see a green PASS or red FAILED. The eina_log 
errors are only in the log file itself. What is the way to trap these 
error messages that will come if we do test error cases? IIRC you did 
eina_log initially so you surely have a good solution here. :)

> just  the time it takes to run it all is one of the reasons I don't
> run them that frequently. :-/

You know that you can run the suites individually. When doing ecore_con 
stuff for example you could ignore the suites like eina and ecore which 
take a lot time. On a bigger patchset I would still expect that you run 
a full make check before pushing due to all the possible side effects 
the changes could have.

POretty sure the time costs of not running it, letting me find them, 
bisect them, report them back to you and then dealing with me over mail 
is higher compared to running them before pushing a patchset and fixing 
them. :P

regards
Stefan Schmidt

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[Stefan Schmidt]

Hello.

On 15/12/16 23:39, Gustavo Sverzut Barbieri wrote:
> s?
>
>
> 1) could someone enable ipv6 on our test bot? It's essential to test
> such api as ipv6 is more and more common (although this specific test
> is no big deal as it's resolving ipv6 localhost)

As I wrote before you have to contact Beber about this. I cc'ed him 
again but his mail system as rejected mails from my address in the past 
so it might be better if you write him directly: Bertrand Jacquin 


> 2) does the bind() test fail? If so I'd like to commit it so it works
> everywhere.

The bind tests works.

IPv6 disabled machine:
0 01:21:27 stefan@e5-build-gentoo-x86_64-1 ~ $ ./ipv6
IPv6 supported: 1

IPv6 enabled machine:
stefan@workmachine efl (master) $ ./ipv6
IPv6 supported: 0

The 0 as success return code here.

regards
Stefan Schmidt

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[Gustavo Sverzut Barbieri]

s?


1) could someone enable ipv6 on our test bot? It's essential to test
such api as ipv6 is more and more common (although this specific test
is no big deal as it's resolving ipv6 localhost)


2) does the bind() test fail? If so I'd like to commit it so it works
everywhere.

On Tue, Dec 13, 2016 at 1:42 PM, Gustavo Sverzut Barbieri
 wrote:
> On Tue, Dec 13, 2016 at 12:10 PM, Stefan Schmidt  
> wrote:
>> hello.
>>
>> On 13/12/16 12:33, Gustavo Sverzut Barbieri wrote:
>>> On Tue, Dec 13, 2016 at 9:28 AM, Stefan Schmidt  
>>> wrote:
 Hello.

 On 13/12/16 12:25, Tom Hacohen wrote:
> On 13/12/16 10:26, Stefan Schmidt wrote:
>> Hello.
>>
>> On 13/12/16 02:15, Gustavo Sverzut Barbieri wrote:
>>> Stefan,
>>>
>>> Could you check the environment where the test runs? In the log
>>> https://build.enlightenment.org/job/nightly_efl_gcc_x86_64/ws/src/test-suite.log
>>> I see:
>>>
>>> WARNING: your system miss '::1 localhost' or '::1 localhost6' in 
>>> /etc/hosts
>>> 98%: Checks: 54, Failures: 1, Errors: 0
>>> tests/ecore_con/ecore_con_test_efl_net_ip_address.c:1149:F:Efl_Net_Ip_Address:ecore_test_efl_net_ip_address_ipv6_resolve_ok:0:
>>> Expected error=0 (success), got 1073741834 (Couldn't resolve host
>>> name) resolving=[::1]
>>>
>>> maybe the machine is not IPv6-enabled? or nswitch.conf disables 
>>> something?
>>
>> Not IPv6 enabled. No entry for ::1 in /etc/hosts and no inet6 address or
>> such shown with ip a. Beber (cc'ed) is handling the systems. He would
>> know why he has IPv6 disabled on them.
>>
>> While I agree that we should have IPv6 everywhere our tests should still
>> work on systems without or do you disagree? I would expect it falls back
>> to IPv4. Something we also need to keep in mind are systems without
>> internet or even without network. But that is a generic problem for the
>> test suite and not really related to your ecore_con revamp.
>
> I think that we are at this point in life that there's no excuse to not
> having IPv6. We shouldn't handle this case in our test suite, but
> instead encourage people to start using it, or at the very least,
> prepare their systems.

 I fully agree (even have native IPv6 here) but we need to be defensive
 what we expect to be available in our test suite.
>>>
>>> well... both are easy to handle... just need to know a reliable way to
>>> check for AF_INET6 support...
>>>
>>> maybe this would do:
>>>
>>> Eina_Bool ipv6_check(void) {
>>> int fd = socket(AF_INET6, SOCK_STREAM, 0);
>>> if (fd != -1) close(fd);
>>> return fd != -1;
>>> }
>>>
>>> could someone check this in an IPv6 disabled machine?
>>
>> Not enough:
>>
>> stefan@workmachine efl (master) $ cat ipv6.c
>> #include 
>> #include 
>> #include 
>> #include 
>>
>> void main(void) {
>> int sd = socket(AF_INET6, SOCK_STREAM, 0);
>> printf("AF_INET6 socket return: %i\n", sd);
>> if (sd != -1) close(sd);
>> }
>> stefan@workmachine efl (master) $ gcc ipv6.c -o ipv6
>> stefan@workmachine efl (master) $ ./ipv6
>> AF_INET6 socket return: 3
>>
>> On the affected slave I get the same:
>> 0 06:02:15 stefan@e5-build-gentoo-x86_64-1 ~ $ ./ipv6
>> AF_INET6 socket return: 3
>>
>> The INET6 address family for sockets is still available even if no IPv6
>> is configured.
>
> what if you bind to an ephemeral port?
>
> #include 
> #include 
> #include 
> #include 
>
> static Eina_Bool
> _ipv6_enabled_check(void)
> {
>int fd, r;
>struct sockaddr_in6 a = {
>  .sin6_family = AF_INET6,
>  .sin6_addr = IN6ADDR_LOOPBACK_INIT,
>};
>
>fd = socket(AF_INET6, SOCK_STREAM, 0);
>if (fd == -1) return EINA_FALSE;
>
>r = bind(fd, (struct sockaddr *), sizeof(a));
>close(fd);
>return r != -1;
> }
>
> int main(void) {
>printf("IPv6 supported: %d\n", _ipv6_enabled_check());
>return 0;
> }
>
>
>
> --
> Gustavo Sverzut Barbieri
> --
> Mobile: +55 (16) 99354-9890



-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[Gustavo Sverzut Barbieri]

On Tue, Dec 13, 2016 at 12:10 PM, Stefan Schmidt  wrote:
> hello.
>
> On 13/12/16 12:33, Gustavo Sverzut Barbieri wrote:
>> On Tue, Dec 13, 2016 at 9:28 AM, Stefan Schmidt  
>> wrote:
>>> Hello.
>>>
>>> On 13/12/16 12:25, Tom Hacohen wrote:
 On 13/12/16 10:26, Stefan Schmidt wrote:
> Hello.
>
> On 13/12/16 02:15, Gustavo Sverzut Barbieri wrote:
>> Stefan,
>>
>> Could you check the environment where the test runs? In the log
>> https://build.enlightenment.org/job/nightly_efl_gcc_x86_64/ws/src/test-suite.log
>> I see:
>>
>> WARNING: your system miss '::1 localhost' or '::1 localhost6' in 
>> /etc/hosts
>> 98%: Checks: 54, Failures: 1, Errors: 0
>> tests/ecore_con/ecore_con_test_efl_net_ip_address.c:1149:F:Efl_Net_Ip_Address:ecore_test_efl_net_ip_address_ipv6_resolve_ok:0:
>> Expected error=0 (success), got 1073741834 (Couldn't resolve host
>> name) resolving=[::1]
>>
>> maybe the machine is not IPv6-enabled? or nswitch.conf disables 
>> something?
>
> Not IPv6 enabled. No entry for ::1 in /etc/hosts and no inet6 address or
> such shown with ip a. Beber (cc'ed) is handling the systems. He would
> know why he has IPv6 disabled on them.
>
> While I agree that we should have IPv6 everywhere our tests should still
> work on systems without or do you disagree? I would expect it falls back
> to IPv4. Something we also need to keep in mind are systems without
> internet or even without network. But that is a generic problem for the
> test suite and not really related to your ecore_con revamp.

 I think that we are at this point in life that there's no excuse to not
 having IPv6. We shouldn't handle this case in our test suite, but
 instead encourage people to start using it, or at the very least,
 prepare their systems.
>>>
>>> I fully agree (even have native IPv6 here) but we need to be defensive
>>> what we expect to be available in our test suite.
>>
>> well... both are easy to handle... just need to know a reliable way to
>> check for AF_INET6 support...
>>
>> maybe this would do:
>>
>> Eina_Bool ipv6_check(void) {
>> int fd = socket(AF_INET6, SOCK_STREAM, 0);
>> if (fd != -1) close(fd);
>> return fd != -1;
>> }
>>
>> could someone check this in an IPv6 disabled machine?
>
> Not enough:
>
> stefan@workmachine efl (master) $ cat ipv6.c
> #include 
> #include 
> #include 
> #include 
>
> void main(void) {
> int sd = socket(AF_INET6, SOCK_STREAM, 0);
> printf("AF_INET6 socket return: %i\n", sd);
> if (sd != -1) close(sd);
> }
> stefan@workmachine efl (master) $ gcc ipv6.c -o ipv6
> stefan@workmachine efl (master) $ ./ipv6
> AF_INET6 socket return: 3
>
> On the affected slave I get the same:
> 0 06:02:15 stefan@e5-build-gentoo-x86_64-1 ~ $ ./ipv6
> AF_INET6 socket return: 3
>
> The INET6 address family for sockets is still available even if no IPv6
> is configured.

what if you bind to an ephemeral port?

#include 
#include 
#include 
#include 

static Eina_Bool
_ipv6_enabled_check(void)
{
   int fd, r;
   struct sockaddr_in6 a = {
 .sin6_family = AF_INET6,
 .sin6_addr = IN6ADDR_LOOPBACK_INIT,
   };

   fd = socket(AF_INET6, SOCK_STREAM, 0);
   if (fd == -1) return EINA_FALSE;

   r = bind(fd, (struct sockaddr *), sizeof(a));
   close(fd);
   return r != -1;
}

int main(void) {
   printf("IPv6 supported: %d\n", _ipv6_enabled_check());
   return 0;
}



-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[Gustavo Sverzut Barbieri]

On Tue, Dec 13, 2016 at 11:54 AM, Stefan Schmidt  wrote:
> Hello.
>
> On 13/12/16 14:09, Felipe Magno de Almeida wrote:
>> On Tue, Dec 13, 2016 at 8:28 AM, Stefan Schmidt  
>> wrote:
>>> Hello.
>>
>> [snip]
>>
>>> I fully agree (even have native IPv6 here) but we need to be defensive
>>> what we expect to be available in our test suite.
>>
>> Why? It is testing, I agree we should need to be defensive in the
>> implementation and interfaces where EFL might run in stranger
>> environments,
>
> If the implementation would handle this all gracefully the test would
> never had been a problem. :)

no no... the code gracefully handles that, but the test is explicit
"resolve ::1 to ::1 and I expect it to work". The test itself should
be conditional and I'm willing to do that, HOWEVER our test bots
should have IPv6 so we check that code.



> but a test that fails on a machine that doesn't
>> handle IPv6 seems fine to me as long as it is rare enough.
>
> We assume IPv6 now, we assume a working internet connection, we assume
> udev for eeze testing, we assume a working dbus setup, in some cases we
> assume a file system which supports extended attributes, etc...
>
> If it is complicated to run make check we will have even less people
> running it. It should be the other way around. I guess I could look at
> anybody here who contributed a few patches this year and see someone who
> broke make check. If it is to complicated or fails for some reason
> people will just stop using it.

our test suite is unusable the way it is... really it lacks
granularity, it takes lots of time and most of the time it looks like
it failed since people forget to trap EINA_LOG to capture errors, then
you get tons of error messages (although the test reports success,
messages confuses users).

just  the time it takes to run it all is one of the reasons I don't
run them that frequently. :-/

-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[Stefan Schmidt]

hello.

On 13/12/16 12:33, Gustavo Sverzut Barbieri wrote:
> On Tue, Dec 13, 2016 at 9:28 AM, Stefan Schmidt  
> wrote:
>> Hello.
>>
>> On 13/12/16 12:25, Tom Hacohen wrote:
>>> On 13/12/16 10:26, Stefan Schmidt wrote:
 Hello.

 On 13/12/16 02:15, Gustavo Sverzut Barbieri wrote:
> Stefan,
>
> Could you check the environment where the test runs? In the log
> https://build.enlightenment.org/job/nightly_efl_gcc_x86_64/ws/src/test-suite.log
> I see:
>
> WARNING: your system miss '::1 localhost' or '::1 localhost6' in 
> /etc/hosts
> 98%: Checks: 54, Failures: 1, Errors: 0
> tests/ecore_con/ecore_con_test_efl_net_ip_address.c:1149:F:Efl_Net_Ip_Address:ecore_test_efl_net_ip_address_ipv6_resolve_ok:0:
> Expected error=0 (success), got 1073741834 (Couldn't resolve host
> name) resolving=[::1]
>
> maybe the machine is not IPv6-enabled? or nswitch.conf disables something?

 Not IPv6 enabled. No entry for ::1 in /etc/hosts and no inet6 address or
 such shown with ip a. Beber (cc'ed) is handling the systems. He would
 know why he has IPv6 disabled on them.

 While I agree that we should have IPv6 everywhere our tests should still
 work on systems without or do you disagree? I would expect it falls back
 to IPv4. Something we also need to keep in mind are systems without
 internet or even without network. But that is a generic problem for the
 test suite and not really related to your ecore_con revamp.
>>>
>>> I think that we are at this point in life that there's no excuse to not
>>> having IPv6. We shouldn't handle this case in our test suite, but
>>> instead encourage people to start using it, or at the very least,
>>> prepare their systems.
>>
>> I fully agree (even have native IPv6 here) but we need to be defensive
>> what we expect to be available in our test suite.
>
> well... both are easy to handle... just need to know a reliable way to
> check for AF_INET6 support...
>
> maybe this would do:
>
> Eina_Bool ipv6_check(void) {
> int fd = socket(AF_INET6, SOCK_STREAM, 0);
> if (fd != -1) close(fd);
> return fd != -1;
> }
>
> could someone check this in an IPv6 disabled machine?

Not enough:

stefan@workmachine efl (master) $ cat ipv6.c
#include 
#include 
#include 
#include 

void main(void) {
int sd = socket(AF_INET6, SOCK_STREAM, 0);
printf("AF_INET6 socket return: %i\n", sd);
if (sd != -1) close(sd);
}
stefan@workmachine efl (master) $ gcc ipv6.c -o ipv6
stefan@workmachine efl (master) $ ./ipv6
AF_INET6 socket return: 3

On the affected slave I get the same:
0 06:02:15 stefan@e5-build-gentoo-x86_64-1 ~ $ ./ipv6
AF_INET6 socket return: 3

The INET6 address family for sockets is still available even if no IPv6 
is configured.

regards
Stefan Schmidt

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[Stefan Schmidt]

Hello.

On 13/12/16 14:09, Felipe Magno de Almeida wrote:
> On Tue, Dec 13, 2016 at 8:28 AM, Stefan Schmidt  
> wrote:
>> Hello.
>
> [snip]
>
>> I fully agree (even have native IPv6 here) but we need to be defensive
>> what we expect to be available in our test suite.
>
> Why? It is testing, I agree we should need to be defensive in the
> implementation and interfaces where EFL might run in stranger
> environments,

If the implementation would handle this all gracefully the test would 
never had been a problem. :)


but a test that fails on a machine that doesn't
> handle IPv6 seems fine to me as long as it is rare enough.

We assume IPv6 now, we assume a working internet connection, we assume 
udev for eeze testing, we assume a working dbus setup, in some cases we 
assume a file system which supports extended attributes, etc...

If it is complicated to run make check we will have even less people 
running it. It should be the other way around. I guess I could look at 
anybody here who contributed a few patches this year and see someone who 
broke make check. If it is to complicated or fails for some reason 
people will just stop using it.

regards
Stefan Schmidt

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[Felipe Magno de Almeida]

On Tue, Dec 13, 2016 at 8:28 AM, Stefan Schmidt  wrote:
> Hello.

[snip]

> I fully agree (even have native IPv6 here) but we need to be defensive
> what we expect to be available in our test suite.

Why? It is testing, I agree we should need to be defensive in the
implementation and interfaces where EFL might run in stranger
environments, but a test that fails on a machine that doesn't
handle IPv6 seems fine to me as long as it is rare enough.

> regards
> Stefan Schmidt

Regards,
-- 
Felipe Magno de Almeida

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[Gustavo Sverzut Barbieri]

On Tue, Dec 13, 2016 at 9:28 AM, Stefan Schmidt  wrote:
> Hello.
>
> On 13/12/16 12:25, Tom Hacohen wrote:
>> On 13/12/16 10:26, Stefan Schmidt wrote:
>>> Hello.
>>>
>>> On 13/12/16 02:15, Gustavo Sverzut Barbieri wrote:
 Stefan,

 Could you check the environment where the test runs? In the log
 https://build.enlightenment.org/job/nightly_efl_gcc_x86_64/ws/src/test-suite.log
 I see:

 WARNING: your system miss '::1 localhost' or '::1 localhost6' in /etc/hosts
 98%: Checks: 54, Failures: 1, Errors: 0
 tests/ecore_con/ecore_con_test_efl_net_ip_address.c:1149:F:Efl_Net_Ip_Address:ecore_test_efl_net_ip_address_ipv6_resolve_ok:0:
 Expected error=0 (success), got 1073741834 (Couldn't resolve host
 name) resolving=[::1]

 maybe the machine is not IPv6-enabled? or nswitch.conf disables something?
>>>
>>> Not IPv6 enabled. No entry for ::1 in /etc/hosts and no inet6 address or
>>> such shown with ip a. Beber (cc'ed) is handling the systems. He would
>>> know why he has IPv6 disabled on them.
>>>
>>> While I agree that we should have IPv6 everywhere our tests should still
>>> work on systems without or do you disagree? I would expect it falls back
>>> to IPv4. Something we also need to keep in mind are systems without
>>> internet or even without network. But that is a generic problem for the
>>> test suite and not really related to your ecore_con revamp.
>>
>> I think that we are at this point in life that there's no excuse to not
>> having IPv6. We shouldn't handle this case in our test suite, but
>> instead encourage people to start using it, or at the very least,
>> prepare their systems.
>
> I fully agree (even have native IPv6 here) but we need to be defensive
> what we expect to be available in our test suite.

well... both are easy to handle... just need to know a reliable way to
check for AF_INET6 support...

maybe this would do:

Eina_Bool ipv6_check(void) {
int fd = socket(AF_INET6, SOCK_STREAM, 0);
if (fd != -1) close(fd);
return fd != -1;
}

could someone check this in an IPv6 disabled machine?


-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[Stefan Schmidt]

Hello.

On 13/12/16 12:25, Tom Hacohen wrote:
> On 13/12/16 10:26, Stefan Schmidt wrote:
>> Hello.
>>
>> On 13/12/16 02:15, Gustavo Sverzut Barbieri wrote:
>>> Stefan,
>>>
>>> Could you check the environment where the test runs? In the log
>>> https://build.enlightenment.org/job/nightly_efl_gcc_x86_64/ws/src/test-suite.log
>>> I see:
>>>
>>> WARNING: your system miss '::1 localhost' or '::1 localhost6' in /etc/hosts
>>> 98%: Checks: 54, Failures: 1, Errors: 0
>>> tests/ecore_con/ecore_con_test_efl_net_ip_address.c:1149:F:Efl_Net_Ip_Address:ecore_test_efl_net_ip_address_ipv6_resolve_ok:0:
>>> Expected error=0 (success), got 1073741834 (Couldn't resolve host
>>> name) resolving=[::1]
>>>
>>> maybe the machine is not IPv6-enabled? or nswitch.conf disables something?
>>
>> Not IPv6 enabled. No entry for ::1 in /etc/hosts and no inet6 address or
>> such shown with ip a. Beber (cc'ed) is handling the systems. He would
>> know why he has IPv6 disabled on them.
>>
>> While I agree that we should have IPv6 everywhere our tests should still
>> work on systems without or do you disagree? I would expect it falls back
>> to IPv4. Something we also need to keep in mind are systems without
>> internet or even without network. But that is a generic problem for the
>> test suite and not really related to your ecore_con revamp.
>
> I think that we are at this point in life that there's no excuse to not
> having IPv6. We shouldn't handle this case in our test suite, but
> instead encourage people to start using it, or at the very least,
> prepare their systems.

I fully agree (even have native IPv6 here) but we need to be defensive 
what we expect to be available in our test suite.

regards
Stefan Schmidt

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[Tom Hacohen]

On 13/12/16 10:26, Stefan Schmidt wrote:
> Hello.
>
> On 13/12/16 02:15, Gustavo Sverzut Barbieri wrote:
>> Stefan,
>>
>> Could you check the environment where the test runs? In the log
>> https://build.enlightenment.org/job/nightly_efl_gcc_x86_64/ws/src/test-suite.log
>> I see:
>>
>> WARNING: your system miss '::1 localhost' or '::1 localhost6' in /etc/hosts
>> 98%: Checks: 54, Failures: 1, Errors: 0
>> tests/ecore_con/ecore_con_test_efl_net_ip_address.c:1149:F:Efl_Net_Ip_Address:ecore_test_efl_net_ip_address_ipv6_resolve_ok:0:
>> Expected error=0 (success), got 1073741834 (Couldn't resolve host
>> name) resolving=[::1]
>>
>> maybe the machine is not IPv6-enabled? or nswitch.conf disables something?
>
> Not IPv6 enabled. No entry for ::1 in /etc/hosts and no inet6 address or
> such shown with ip a. Beber (cc'ed) is handling the systems. He would
> know why he has IPv6 disabled on them.
>
> While I agree that we should have IPv6 everywhere our tests should still
> work on systems without or do you disagree? I would expect it falls back
> to IPv4. Something we also need to keep in mind are systems without
> internet or even without network. But that is a generic problem for the
> test suite and not really related to your ecore_con revamp.

I think that we are at this point in life that there's no excuse to not 
having IPv6. We shouldn't handle this case in our test suite, but 
instead encourage people to start using it, or at the very least, 
prepare their systems.

--
Tom.


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[Stefan Schmidt]

Hello.

On 13/12/16 02:15, Gustavo Sverzut Barbieri wrote:
> Stefan,
>
> Could you check the environment where the test runs? In the log
> https://build.enlightenment.org/job/nightly_efl_gcc_x86_64/ws/src/test-suite.log
> I see:
>
> WARNING: your system miss '::1 localhost' or '::1 localhost6' in /etc/hosts
> 98%: Checks: 54, Failures: 1, Errors: 0
> tests/ecore_con/ecore_con_test_efl_net_ip_address.c:1149:F:Efl_Net_Ip_Address:ecore_test_efl_net_ip_address_ipv6_resolve_ok:0:
> Expected error=0 (success), got 1073741834 (Couldn't resolve host
> name) resolving=[::1]
>
> maybe the machine is not IPv6-enabled? or nswitch.conf disables something?

Not IPv6 enabled. No entry for ::1 in /etc/hosts and no inet6 address or 
such shown with ip a. Beber (cc'ed) is handling the systems. He would 
know why he has IPv6 disabled on them.

While I agree that we should have IPv6 everywhere our tests should still 
work on systems without or do you disagree? I would expect it falls back 
to IPv4. Something we also need to keep in mind are systems without 
internet or even without network. But that is a generic problem for the 
test suite and not really related to your ecore_con revamp.

regards
Stefan Schmidt

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[Gustavo Sverzut Barbieri]

Stefan,

Could you check the environment where the test runs? In the log
https://build.enlightenment.org/job/nightly_efl_gcc_x86_64/ws/src/test-suite.log
I see:

WARNING: your system miss '::1 localhost' or '::1 localhost6' in /etc/hosts
98%: Checks: 54, Failures: 1, Errors: 0
tests/ecore_con/ecore_con_test_efl_net_ip_address.c:1149:F:Efl_Net_Ip_Address:ecore_test_efl_net_ip_address_ipv6_resolve_ok:0:
Expected error=0 (success), got 1073741834 (Couldn't resolve host
name) resolving=[::1]

maybe the machine is not IPv6-enabled? or nswitch.conf disables something?

The failing test is trying getaddrinfo("::1", "0", hints={ai_family =
AF_UNSPEC.. }), thus it shouldn't fail.



On Mon, Dec 12, 2016 at 9:54 PM,   wrote:
> https://build.enlightenment.org/job/nightly_efl_gcc_x86_64/1417/Changes:
>
> [jpeg] efl_canvas_proxy: fix the parameter of EINA_COW_WRITE
>
> [barbieri] efl_net: spell check s/revogation/revocation/g
>
> [barbieri] yoda-style inactivity timeout.
>
> [barbieri] Efl_Future: class name (string) using "." for namespace.
>
> [barbieri] efl_net: move error COULDNT_RESOLVE_HOST to broader scope.
>
> [barbieri] efl_net: add Efl.Net.Ip_Address
>
> [barbieri] efl_net_dialer_http: fix reference check.
>
> [barbieri] efl_net_dialer_http: fix HEAD requests.
>
> [jpeg] elm_spinner: Spinner internal focus logic fixed to following new 
> focused
>
> [andy] elm_code: Fix parameter ordering for consistency
>
> [Stefan Schmidt] docs: ecore_con: document newly added extern struct item
>
> [Stefan Schmidt] docs: ecore_con: fill gaps in newly added efl_net_ip_address
>
> [daniel.hirt] Ui text: implement scrolling with line wrap
>
> [daniel.hirt] Ui text: fix selection handler behavior
>
> [daniel.hirt] Ui text: disable selection handler from test
>
> [daniel.hirt] Ui text: implement non-editable beahvior
>
> [daniel.hirt] Ui text interactive: fix passing of wrong object
>
> [daniel.hirt] Canvas text: call "changed" on annotation_insert
>
> [daniel.hirt] Ui text: move tests to test_efl_ui_text.c
>
> [daniel.hirt] Canvas text: call "changed" on style_set
>
> [daniel.hirt] Ui text: remove unimplemented imf api
>
> [barbieri] efl_net_ip_address: improve docs.
>
> [barbieri] test efl_net_ip_address: check if /etc/hosts has '::1 localhost'
>
> [andy] elm_code: Fix tests for parameter reordering
>
> [barbieri] add missing includes for BSD.
>
> [barbieri] test efl_net_ip_address: also check localhost6.
>
> [barbieri] efl_net_ip_address: make coverity happy.
>
> [barbieri] ecore_con_legacy: fix coverity issues (use after free)
>
> [Stefan Schmidt] ethumb: fix resource leak introduced in file path 
> sanitization rework
>
> [Stefan Schmidt] elm: theme: avoid double free in theme version check
>
> [bdilly] Evas: Add seat_event_filter_set()/get() API.
>
> [bdilly] Efl.Canvas.Object: Override efl_event_callback_[legacy]_call.
>
> [bdilly] Evas: Objects must not be focused with the seat is not allowed to 
> emit
>
> [bdilly] Evas: Add event filter example.
>
> --
> [...truncated 7241 lines...]
>   CC   tests/eeze/tests_eeze_eeze_suite-eeze_test_sensor.o
>   CC   tests/eeze/tests_eeze_eeze_suite-eeze_test_udev.o
>   CCLD tests/efreet/efreet_suite
>   CC   tests/eio/tests_eio_eio_suite-eio_suite.o
>   CC   tests/eio/tests_eio_eio_suite-eio_model_test_file.o
>   CC   tests/eio/tests_eio_eio_suite-eio_model_test_monitor_add.o
>   CC   tests/eio/tests_eio_eio_suite-eio_test_monitor.o
>   CC   tests/eio/tests_eio_eio_suite-eio_test_sentry.o
>   CC   tests/eio/tests_eio_eio_suite-eio_test_file.o
>   CC   tests/eio/tests_eio_eio_suite-eio_test_manager.o
>   CC   tests/eio/tests_eio_eio_suite-eio_test_manager_xattr.o
>   CC   tests/eio/tests_eio_eio_suite-eio_test_xattr.o
>   CC   tests/eio/tests_eio_eio_suite-eio_test_common.o
>   CC   tests/eio/tests_eio_eio_suite-eio_test_map.o
>   CC   tests/eio/tests_eio_eio_suite-eio_test_eet.o
>   CC   tests/edje/tests_edje_edje_suite-edje_suite.o
>   CC   tests/edje/tests_edje_edje_suite-edje_test_edje.o
>   CC   tests/elementary/tests_elementary_elm_suite-elm_suite.o
>   CC   tests/elementary/tests_elementary_elm_suite-elm_test_helper.o
>   CC   tests/elementary/tests_elementary_elm_suite-elm_test_atspi.o
>   CC   tests/elementary/tests_elementary_elm_suite-elm_test_check.o
>   CC   
> tests/elementary/tests_elementary_elm_suite-elm_test_colorselector.o
>   CC   tests/elementary/tests_elementary_elm_suite-elm_test_entry.o
>   CC   tests/elementary/tests_elementary_elm_suite-elm_test_init.o
>   CC   tests/elementary/tests_elementary_elm_suite-elm_test_list.o
>   CC   tests/elementary/tests_elementary_elm_suite-elm_test_button.o
>   CC   tests/elementary/tests_elementary_elm_suite-elm_test_image.o
>   CC   tests/elementary/tests_elementary_elm_suite-elm_test_photo.o
>   CC