sinan eunit task specialization question

[alisdair sullivan]

Coming from rebar, all my eunit tests are disabled in production releases via a 'TEST' macro definition. Rebar automatically defines 'TEST' when building for eunit runs. Trying to accomplish something similar with sinan I tried:

{compile_args, [{task, eunit}], [{d, 'TEST'}]}.

in my sinan.config, but this apparently does not apply to the build step run before the eunit step. is there anyway to use sinan.config to define 'TEST' only when running the eunit task?

thanks

alisdair

[Eric Merritt]

Alisdair,

TLDR-------------------------

This is going to get a bit long just because I want to be complete.

 do just

  

    {compile_args, [{d, 'TEST'}]}.

or better yet define a new release

   {compile_args, [{release, mydbgrelease}], [{d, 'TEST'}]}.

and then build with 

   sinan -r mydbgrelease

--------------

  Sinan and Rebar are a bit different in a number of ways. We try to

be consistant in how and what the different tasks in Sinan do. So for

example building things only happens in the build task and running

eunit tests only happens in the eunit task etc.

In this case you have specified compile args for the eunit task when,

by the time the eunit task is run, compilation has already happened

(eunit depends on build).

With that in mind there are two strategies to pursue. One is

specifying the compile args generally (no need to specialize) so the

build task picks them up and they get built into the code base. This

is the path that I and most of the folks using sinan take. No reason

they shouldn't be there unless you are very size constrained. Oh,

though we tend to define the macros for tests a bit differently

generally. If you define your tests as follows it works out of the

box. Of course, its the inverse of what you are doing so it might or

might not be good.

-ifndef(NOTEST).

-include_lib("eunit/include/eunit.hrl").

<my test functions here>

-endif.

Again, this is what I do and I think its probably the best way to

go. However, it may not be what you actually want. What you may want

is a production build that contains no test artifacts and a test build

that you use for testing.

You can get that easily by specializing your testing symbols on a new

release. as follows

   {compile_args, [{release, mydbgrelease}], [{d, 'TEST'}]}.

and then build with 

   sinan -r mydbgrelease

I hope this makes sense. If not feel free to ask more questions.

alisdair

--
You received this message because you are subscribed to the Google Groups "erlware-questions" group.
To post to this group, send email to erlware-...@googlegroups.com.
To unsubscribe from this group, send email to erlware-questi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/erlware-questions?hl=en.