sinan eunit task specialization question

Skip to first unread message

alisdair sullivan

May 17, 2012, 12:49:07 AM5/17/12
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?



Eric Merritt

May 17, 2012, 11:03:09 AM5/17/12


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.


<my test functions here>


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.


You received this message because you are subscribed to the Google Groups "erlware-questions" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply all
Reply to author
0 new messages