sinan eunit task specialization question

20 views
Skip to first unread message

alisdair sullivan

unread,
May 17, 2012, 12:49:07 AM5/17/12
to erlware-...@googlegroups.com
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

unread,
May 17, 2012, 11:03:09 AM5/17/12
to erlware-...@googlegroups.com
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.

Reply all
Reply to author
Forward
0 new messages