[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Test results as XML files


Actually on item #2, it looks like we are duplicating a functionality in 
some compilers including GCC and the embedded compiler I use, with regards 
to "pre-includes" or "forced includes". This would allow me to basically 
get the same functionality in practice. I was not aware of this before.

Our fix may still be worth including for compilers that do not have this 
ability, but I am not immediately aware of any that don't. 

Thanks,
-James



From:   asn@xxxxxxxxxxxxxx
To:     James.Munns@xxxxxxxxxxxxx, 
Cc:     cmocka@xxxxxxxxxxxxxx
Date:   09.02.2015 13:30
Subject:        Re: Test results as XML files



On 09.02.2015 10:54, James.Munns@xxxxxxxxxxxxx wrote:
> Hey Andreas,

Hi James,

> a couple of comments. The background for this is that I
> am running tests using both GCC (for CI) as well as using an embedded
> compiler compiling to a simulator target (for the sake of developers
> using the same IDE as primary development). This may not be within the
> scope of your development, but may be useful to other users,
> portability wise.
> 
> CMocka seems to make some assumptions at compile time, more or less
> that the target environment is Unix-like/GCC compiled or
> Windows-like/VS compiled. This breaks compilation for me in a couple
> ways.

these are the targets which are in our dashboard at 
https://mock.cryptomilk.org/
What breaks there will be fixed. Feel free to setup a nightly build 
which submits
result to our dashboard :)

http://git.cryptomilk.org/projects/cmocka.git/tree/tests/ctest-default.cmake


I the file to copy and modify. Then you simply run:

   ctest -S ctest-default.cmake

> 1: My embedded compiler defines some, but not all of the exception
> signals in the array in cmocka.c:281. This is not new to cMocka 1.0,
> for now I have added in a compiler flag to change the definition of
> this array. It would be nice to have an option to be blind of
> exceptions at compile time (sort of like 'handle_exceptions', but at
> compile time rather than runtime).

Which ones are defined? I guess they are preprocessor defines, right?

#define SIGSEGV 11

If yes, we can simply add guards.

static const int exception_signals[] = {
     SIGFPE,
     SIGILL,
     SIGSEGV,
#ifdef SIGBUS
     SIGBUS,
#endif
#ifdef SIGSYS
     SIGSYS,
#endif
};


Please let me know which ones are defined in your environment.

> 
> 2: I had some problems with the 'uintptr_t' logic in cmocka.h:101.
> Probably nothing unique about that type, except that it was defined in
> another header file. Unfortunately I have no way of "informing"
> cmocka.h about my other 'stdint.h' file, and a re-def of uintptr_t
> makes the compiler sad. Again, this is not new to cMocka 1.0. It might
> be nice to have some sort of user defined includes? Something like the
> following at the top of the headers?:
> 
> #ifdef _CMOCKA_USER_INCLUDES
>  #include "cmocka_user_includes.h"
> #endif

We could add something like that.

> 3. This one actually is new to cMocka 1.0. My compiler defines time.h,
> but does not define the struct 'timespec'. Similar to my exceptions
> comment, there is some handling for targets not supporting test
> timing, however this is not completely transparent at compile time. I
> could fill in the definition of timespec, however I dont really have
> any way of letting cmocka.c know where to find it (modifying my
> compiler's time.h is not an option). It would be nice to have a
> compiler flag to completely exclude the timing component.

I will add a configure check for the struct and guard it.


Thanks,


  -- andreas




-- 
MSA Technologies and Enterprise Services GmbH 
Firmensitz (Registered Headquarter): Thiemannstr. 1, 12059 Berlin 
Ust.-ID: DE 237 346 046 
Registergericht (Register Court): Amtsgericht Berlin-Charlottenburg Nr.93, HRB 92728 B 
Geschäftsführer (Managing Director): Richard W. Roda, Kenneth D. Krause, Steven C. Blanco 

Follow-Ups:
Re: Test results as XML filesAndreas Schneider <asn@xxxxxxxxxxxxxx>
References:
Re: Test results as XML filesJames.Munns@xxxxxxxxxxxxx
Re: Test results as XML filesAndreas Schneider <asn@xxxxxxxxxxxxxx>
Re: Test results as XML filesAndreas Schneider <asn@xxxxxxxxxxxxxx>
Re: Test results as XML filesJames.Munns@xxxxxxxxxxxxx
Re: Test results as XML filesasn@xxxxxxxxxxxxxx