sinan needs a command line function that will return to standard out the
erts vsn that it is compiling for. Having another function that returns
the compiler version and yet another that returns the Erlang version string
would not hurt either. The responses should be easily read from the
command line.

This proper test failed and needs to be resolved

{{'$call',sin_config,remove,[{'','','','','',''},{'$call',sin_config,'add',[{'','','','','',''},0,{'$call',sin_config,new,[]}]}]},{'','','','','','*'},0}

suggested by @yrashk

In single app projects the project name and version should not be required in the build config.

the sinserv process crashes silently and gives a python error to the user if the build config is un parsable. This is non optimal.

Sinan shouldn't copy what are obviously build artifacts into the sinan
build area. Examples of this are *.beam files. It should ignore these to
the best of its ability.

When the user miss-types an application name when generating tests for cucumber. Sinan generates it regardless of if the application exists in the project or not.

just run tests in the module that changed

$ sinan help
Unable to build got :
[Errno 97] Address family not supported by protocol

Here are the sinan details:

$ faxien describe-app sinan

Describing Application: sinan

description:
Build system for erlang
vsn:
0.16.2.4
modules:
sinan, sin_release, sin_edoc, sin_shell,
sin_config_registry, sin_config_sup, sin_build_config,
sin_wip, sin_utils, sin_clean, sin_depends, sin_sig,
sin_gen, sin_resolver, sin_skel, sin_hooks,
sin_config_parser, sin_group_leader,
sin_group_leader_sup, sin_erl_builder,
sin_build_arg_parser, sin_dist_builder, sin_discover,
sin_file_logger, sin_release_builder, sin_print_handler,
sin_test, sin_analyze, sin_app, sin_sup, sin_help,
sin_version
registered:
sin_sup
versioned_dependencies:
ibrowse >= 1.2.4.1
ewrepo >= 0.2.3
ktuo >= 0.4.0.0
applications:
kernel, stdlib, compiler, edoc, sasl, syntax_tools,
ibrowse, ktuo, ewrepo, ewlib, tools, dialyzer, xmerl,
mnesia, etask, sgte, parsetools, asn1
mod:
{sin_app,[]}

ok

test

Sinan does apparently not provide a possibility to reload code. Such a
feature is highly desired, especially when people have been using
Emakefiles and make:all([load]) for code reloading and now consider to
switch to erlware/faxien/sinan.

If there are apps in a local repo compiled for erts 5.7.3 and sinan is only
compliling for 5.7.2 then when creating a dist sinan should not be pulling in
apps that are compiled for 5.7.3. It should pull the app with the highest
version that is compiled for anything up to the compiler version that sinan
itself is compiling for.

This bug leads currently to releases for version say, 5.7.3 that contain apps
for 5.7.3 which should never happen.

Right now no validity checking is done for *.app files. Its assumed that
whatever is there is good and correct. For example the name of the app
should match the application directory that it is in.

What is the expected output? What do you see instead?

We should do some validity checking when the .app file changes

The sinan generated release path should match the OTP version requirements

requested @yrashk

Answering "yes" to the "Is this a single application project" question fails.
The /app/doc directory is being created twice - once in the build_out_skeleton function and again in the build_out_application function which dies with an eexists error.

{"init terminating in do_boot",{function_clause,[{sin_task_gen,is_made,["/app/doc",{error,eexist}]},{sin_task_gen,make_dir,1},{sin_task_gen,build_out_application,4},{sin_task_gen,build_out_applications,1},{sin_task_gen,get_project_information,2},{lists,foldl,3},{sinan,run_task,3},{sinan,do_task,3}]}}

there should be a pluggable module that you can add to run a build on files of a specified type.

Feature: Sinan should all configuration at the $HOME dir level
In order to allow a developer to set cross project defaults (and defaults not in the project config)
As an Erlang Developer
I want to sinan to be able to look in the home directory for a config that provides defaults

Scenario: Allow setting of the home directory
Given a generated project
And a non-standard home directory
When a build step is run on this project
And a home directory is specified on the command line
Then build the app normally
And have the home directory correctly specified in the build state

Scenario: Allow config in the home directory
Given a generated project
And a non-standard home directory
And a sinan config in that home directory
When a build step is run on this project
And a home directory is specified on the command line
Then sinan uses the config in the alternate home directory
And builds the app normally
And have the home directory correctly specified in the build state

@tsloughter should also be interested in this as well

Useful for local non-production builds (faster)

Just from reading the documentation, and playing a little with sinan
a few months ago, I have some comments on singen.

• It would be nice to have something like ~/.sinan that can contain
  default values especially for repositories and copyright notices.
• currently singen always generates MYAPP_app.erl and
  MYAPP_sup.erl, but they are not needed if it is a pure library
  application. It would be nice to be able to select if they should
  be generated or not.

Sinan breaks down when parse transforms are in an included hrl file.

What steps will reproduce the problem?

1. Add _hooks into the base of the project
2. create a fax_post_install hook file
3. run sinan dist

What is the expected output? What do you see instead?

This is from kernel.log

class: exit
reason: {shutdown,
{gen_server,call,
[eta_engine,
{run,sinan,build,"1771b9f2-804f-48ea-aa7a-982435b2288e",
#Fun<sin_hooks.0.51987102>},
infinity]}}
stack: [{gen_server,call,3},
{sinan,do_task,4},
{swa_crary_handler,handler,2},
{crary_ctrl,call_handler,2},
{crary_util,'-spawn_link/1-fun-0-',1},
{proc_lib,init_p,3}]

Right now sinan reports missing dependencies one at a time. It should report them all at once.

Add the possibility to run eunit tests also in directories different from src.

Maybe a parameter to specify where tests reside could be passed in the
_build.cfg?

Provide a function that will update the version of the project and another
that will update the version of specific apps within the project.
Something to the effect up

sinan vup <major|minor|patch>
to update the project version and

sinan vup <major|minor|patch>
to update the version of an application

For strange version strings this would not be expected to work but for
things matching [0-9]+[.-][0-9][.-][0-9]([-][a-zA-Z]+)? it should be
made to work.

make the _build// look like the standard otp release distributable.

requested by @yrashk

What steps will reproduce the problem?

1. Add compile_args to _build.cfg as shown below (or any similar macro).
2. The option does not make it to the compiler command. It is not in the
   beam file either.

task : {
build : {
compile_args : "+debug_info -DDEBUG_LOGGING"
}
}

In fact I added code to sinan (patch forthcoming) to show the compiler args
and the above seems to be ignored.

=INFO REPORT==== 17-Sep-2008::20:49:03 ===
[RUN:"1771b9f2-804f-48ea-aa7a-982435b2288e"] build:compile_options
generated event:Compile Options: [{warn_format,1},
debug_info,

{outdir,"/home/efine/work/blah/otp/_build/development/apps/yaws-1.77/ebin"},
strict_record_tests,return_errors,return_warnings,
{i,"/home/efine/work/blah/otp/lib/yaws/include"},
{i,"/home/efine/.sinan/repo/stdlib-1.15.3/include"},
{i,"/home/efine/.sinan/repo/kernel-2.12.3/include"},
{i,"/home/efine/.sinan/repo/eunit-2.0/include"}]

Add the ability to include an item to the sinan.config file which defines the options to edoc when doing "SINAN DOC".

You could call the config entry "edoc_options".

This config item defines the proplist that is included in the call to edoc. The defined proplist is added to the default one that defines the destination of the results [".docs"] except when a property is "doc". In the event that the config proplist includes "dir", the "dir" supercedes the default value.

I'd use it to define the stylesheet to use and the version number of the documented package.

So I'd include {edoc_options, [{def,{version,"2.6"}},{stylesheet_file, ".//doc/eg_stylesheet.css"}]}.

Carl

What steps will reproduce the problem?

1. insert a EUnit debug macro somewhere in a testcase for example
   the macro ?debugVal(Expr)
2. run sinan test
3. done

What is the expected output? What do you see instead?
I expect to see the output of the debug macro but instead I see only the
status of the testcases. It doesn't matter if the testcase fails or succeeds.

What version of the product are you using? On what operating system?
OS: Mac OSX 10.5.5
Erlang: R12B
EUnit: 4.5.2
Sinan: 0.11.0.0

What steps will reproduce the problem?

1. sinan task:build:compile_args="+debug_info -W1"

What is the expected output? What do you see instead?

efine@ender:~/work/integrat/xhg/otp$ sinan
task:build:compile_args="+debug_info -W1"
Usage: sinan [options] [task [server-variable server-value ...]]

Server arguments (pairs of variable and values) are complex. There are
always sane defaults so you shouldn't need them, but you may. To get
information about server arguments read the sinan documentation.

sinan: error: no such option: -W

What version of the product are you using? On what operating system?
0.10.0.14

Please provide any additional information below.

I've attempted to use the new sinan with a project with a hook in it and it seems to blow everything up:

starting: depends
build problem error:badarg:[{erlang,open_port,
[{spawn,
"/home/tristan/Devel/claimstrade/_hooks/pre_build"},

I'm not positive its due to the hook but I'm also trying to build another project on this same system without a hook that gave me a different error.

I sent the other projects error in my email to the sinan alpha thread.

@tsloughter

Please support debian packaging in the sinan repo. This should allow
updates and repackaging to be much much easier.

As an aside remove the launchpad erlang-sinan project as redundant

Do this in the same way as rebar

requested by @yrashk

hen sinan builds a project it copies the non-beam parts of the OTP
application into the build area. However, it doesn't remove old files from
that copied area that no longer exist in the source. Instead it should make
the copied app mirror the source app.

the ~/.sinan/config/sinserv-.config
file never changes.

I've been repeatedly pulling the entire erlang system into different
directories:
~/erlang
~/erw
~/ew2

etc etc.

I'm currently in ~/erw (erlware is at ~/erw/erlware).
I've been updating .bashrc to put ~/erw/erlware/bin
So everything seems to work,
but apparently sinserv has been checking against ~/erlang..., my
original install location.
I deleted that config file, re-ran sinan and it works fine.

I'd still like to know how to step in to sinan though, so I can track
this stuff down faster -- also, maybe there can be a verbose logging
flag so that sinan can tell me exactly what it thinks it is doing.

Only print dependency detail in verbose mode

The release files contain the atom 'load' in the app tuples causing the boot file to be incorrect.

y problem is that I often have backup of .erl files in the source dir
named .erl~. This should be ignored when building the .tar.gz files for the
project.

A solution to add more flexibility might be something like:
ignore : ["_",
".",
{regex, "*.erl~"}]

in the _build.cfg and then using one of the available regexp modules to
check if a file has to be packaged.

Sinan doesn't yet handle cross project dependencies. ie, if you
have 2 projects you are working on and one depends on the other there
isn't really any way to tell that to sinan. It always looks to the
current project or the remote repository for dependencies. It needs to
be able to look to a local project or even a local on-disc repository.

What steps will reproduce the problem?

1. sinan release

What is the expected output? What do you see instead?
A .rel that contains only the applications in my system.
eunit is used internally by sinan and should not be included unless
it is listed in one of the .app file of my applications.

What version of the product are you using? On what operating system?
sinan 0.10.0.1
Linux

Please provide any additional information belo

Rebar has a helpful c_src building plugin that folks like. no need not to include similar stuff in sinan.

Considering the international nature of sinan, it should use the erlang
get_text library to provide multiple language output.

What steps will reproduce the problem?

1. sinan build

What is the expected output? What do you see instead?

The compiler options are not shown anywhere when building, so I added a log
message to show the options before each application is compiled. This is
needed because if using the compile_args option in _build.cfg, there's no
way to know if it actually works. It's also really useful to know which
flags are being used.

What version of the product are you using? On what operating system?
0.10.0.14

Please provide any additional information below.
Patch forthcoming.

Running 'sinan help' on version 0.20.0.2 results in the following error:

~/src/sinan $ sinan help
starting: help
{"init terminating in do_boot",{undef,[{sin_task,get_tasks,[]},{sin_task_help,help,1},{lists,foldl,3},{sinan,run_task,3},{init,start_it,1},{init,start_em,1}]}}

Modifying sin_task.erl to export get_tasks/0 fixes the problem.

If this is indeed q sinan bug, it's a showstopper.

I don't have time to try to reproduce this now, but will explain what happened.

I had made a change in an application (call it A) on which another
application, B, depended. I succesfully built and installed A.

When I built B, I got a compile warning telling me that I was not exporting
something expected by a behavior in A. But I had just rebuilt that
particular module in A with a change to the behavior exports, so I knew
that was wrong because I was exporting the required callback properly in B.

I tried everything, including rebuilding everything, checking the code
path, and so on. I knew I was onto something when I loaded the module in
app A that was exporting the behavior in sinan shell and saw what I
expected, not what the compile was telling me.

When I killed sinserv (for the 10th time today), and rebuilt A, it worked
fine (no more warnings).

I can only assume that sinserv caches module info for improved speed or
something, and doesn't update the cache properly.

What steps will reproduce the problem?

1. go to a project's root folder
2. $ sinan analyze

What is the expected output? What do you see instead?
I expect that it will analyze the project's code
Instead it displays the following error:
Starting analyzation, this may take awhile ...
function_clause: [{sin_analyze,get_code_paths,
["/home/pieter/.sinan/repo",
[{kernel,"2.13.4",[],
"/usr/local/lib/erlang/lib/kernel-2.13.4"},
{stdlib,"1.16.4",
[kernel],
"/usr/local/lib/erlang/lib/stdlib-1.16.4"},
{eunit,"2.1.4",
[stdlib],
"/usr/local/lib/erlang/lib/eunit-2.1.4"}],
[]]},
{sin_analyze,generate_local_plt,2},
{sin_analyze,run_analyzer,3},
{sin_analyze,analyze,1},
{eta_task_runner,apply_task,3},
{eta_task_runner,execute_task_stack,4},
{eta_task_runner,run_tasks,4},
{eta_task_runner,do_tasks,4}]
Task failed
run complete with faults

What version of the product are you using? On what operating system?
Installed Releases (Erlang standalone services):
erl 5.7.4.2
faxien 0.43.1.15 | 0.43.1.10 | 0.43.1.9
sinan 0.16.2.4
ok

Ubuntu 9.10

Please provide any additional information below.

What steps will reproduce the problem?

Put bogus name in .app file and run sinan

What is the expected output? What do you see instead?

Expected output is something like app name and .app file name don't match.
What I get instead is:

[sin_erl_builder fault!!] {badmatch,{error,enoent}}: [{sin_utils,copy_dir,4},
{sin_erl_builder,build_app,4},
{lists,foreach,2},
{sin_erl_builder,build,1},
{eta_task_runner,apply_task,3},
{eta_task_runner,execute_task_stack,4},
{eta_task_runner,run_tasks,4},
{eta_task_runner,do_tasks,4}]

Please use labels and text to provide additional information.