>    $> sinan help ct

> and get comprehensive documentation for the ct app. I also dislike
> duplicating documentation, so its more important that it be in 'help'
> then that it be on a page.

> I would like to have a solution that solves both.

> On Sat, May 5, 2012 at 12:06 PM, Tristan Sloughter
> <tristan.slough...@gmail.com> wrote:
> > Huh? Why would this not be a page for the website?

> > On Sat, May 5, 2012 at 12:01 PM, Eric Merritt <ericbmerr...@gmail.com>
> > wrote:

> >> this is the actual in source help documentation. It makes it slightly
> >> harder to publish in that way

> >> On Sat, May 5, 2012 at 11:46 AM, Tristan Sloughter
> >> <tristan.slough...@gmail.com> wrote:
> >> > I'd suggest publishing this directly, before review
> >> > to http://erlware.github.com/sinan/

> >> > That way it is easier to read :). No one will stumble on it before any
> >> > fixes
> >> > are added I'm sure.

> >> > Tristan

> >> > On Sat, May 5, 2012 at 11:44 AM, Eric Merritt <ericbmerr...@gmail.com

> >> > wrote:

> >> >> ct Task
> >> >> =======

> >> >> The ct task is a method of running the [Common Test
> >> >> Framework](
> http://www.erlang.org/doc/apps/common_test/users_guide.html)
> >> >> on
> >> >> a the
> >> >> project. You should be familiar with the common test framework to use
> >> >> this
> >> >> task.

> >> >> Configuration
> >> >> -------------

> >> >> In this case Sinan does not do *any* configuration for you outside of
> >> >> setting up the proper code paths. Sinan does however give you several
> >> >> variables
> >> >> that you can use in your options (at least those options that contain
> >> >> directory
> >> >> specifications).

> >> >> These exist to help you configure your tests. It is suggested that
> you
> >> >> put
> >> >> all
> >> >> output under the 'build_dir' and no in your project itself. Otherwise
> >> >> sinan
> >> >> clean will be *unable* to clean the project correctly. However, this
> is
> >> >> completely up to you.

> >> >> ### Available Variables

> >> >> These are the variables available in your configuration options.

> >> >> *Project Dir*

> >> >> This is the project directory. This should be the same as CWD, since
> >> >> Sinan
> >> >> sets
> >> >> the projec directory to be the current directory.

> >> >>    $project_dir$

> >> >> *Build Root*

> >> >> The build root points to the top level of the build directory. This
> >> >> usually
> >> >> points `$project_dir$/_build`. You shouldn't put too much at this
> >> >> level directory,
> >> >> because you can have multiple releases that may step on each other.

> >> >>   $build_root$

> >> >> *Build Dir*

> >> >> Build dir points to the build output directory, that is the release
> >> >> directory
> >> >> where all build output ends up.

> >> >>   $build_dir$

> >> >> *Release*

> >> >> This is simply the name of the currently active release.

> >> >>    $release$

> >> >> *Release Version*

> >> >> This is the currently set version of the *release*.

> >> >>   $release_vsn$

> >> >> *Apps Dir*

> >> >> This points to the 'lib' dir of the release directory. This is
> >> >> equivalent
> >> >> to
> >> >> `$apps_dir$/lib`.

> >> >>   $apps_dir$

> >> >> *Release Dir*

> >> >> This points to the directory containing the release metadata. It is
> >> >> equivalent
> >> >> to `$build_dir$/releases/$release_vsn$`

> >> >>   $release_dir$

> >> >> *Home Dir*

> >> >> This is simply the user's home directory.

> >> >>   $home_dir$

> >> >> *Application Directory*

> >> >> Lets say we had an application called foo. The variable `$foo_dir$`
> >> >> would
> >> >> point
> >> >> to the root directory of that application. So in this model the ebin
> >> >> directory
> >> >> of foo would look like '$foo_dir$/ebin'.

> >> >>    $<app_name>_dir$

> >> >> *Application Version*

> >> >> The is similar to `$<app_name>_dir$` except contains the version of
> the
> >> >> application instead of its dir. So for our foo example if we wanted
> the
> >> >> version
> >> >> of foo we would do `$foo_vsn$`.

> >> >> ### Multiple Common Test Configurations

> >> >> Sinan give you the ability to have multiple common test
> configurations.
> >> >> The
> >> >> configurations are are specified as follows.

> >> >>    {ct_config, [{config_name(), terms()}]}.

> >> >> Lets say we had a configuration call alternate in our bar release. We
> >> >> might
> >> >> configure it as follows.

> >> >>    {ct_config, [{alternate, [{dir, \"$foo_dir$/test\"}]}]}.

> >> >> To run that configuration you would simple call this from the command
> >> >> line

> >> >>    $> sinan ct alternate

> >> >> ### Available Configuration Options

> >> >> These are exactly the same options taken by
> >> >> [ct:run/1](http://www.erlang.org/doc/man/ct.html#run-1). Look there
> for
> >> >> the
> >> >> common test documentation.

> >> >>    {dir, TestDirs}                      % Variables Supported
> >> >>    {suite, Suites}
> >> >>    {group, Groups}
> >> >>    {testcase, Cases}
> >> >>    {spec, TestSpecs}
> >> >>    {label, Label}
> >> >>    {config, CfgFiles}                   % Variables Supported
> >> >>    {userconfig, UserConfig}             % Variables Supported
> >> >>    {allow_user_terms, Bool}
> >> >>    {logdir, LogDir}                     % Variables Supported
> >> >>    {silent_connections, Conns}
> >> >>    {stylesheet, CSSFile}                % Variables Supported
> >> >>    {cover, CoverSpecFile}               % Variables Supported
> >> >>    {step, StepOpts}
> >> >>    {event_handler, EventHandlers}
> >> >>    {include, InclDirs}                  % Variables Supported
> >> >>    {auto_compile, Bool}
> >> >>    {create_priv_dir, CreatePrivDir}
> >> >>    {multiply_timetraps, M}
> >> >>    {scale_timetraps, Bool}
> >> >>    {repeat, N}
> >> >>    {duration, DurTime}
> >> >>    {until, StopTime}
> >> >>    {force_stop, Bool}
> >> >>    {decrypt, DecryptKeyOrFile}          % Variables Supported
> >> >>    {refresh_logs, LogDir}               % Variables Supported
> >> >>    {logopts, LogOpts}
> >> >>    {basic_html, Bool}
> >> >>    {ct_hooks, CTHs}
> >> >>    {enable_builtin_hooks, Bool}

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

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

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

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

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