erlware-deprecated / sinan Goto Github PK
View Code? Open in Web Editor NEWErlang/OTP oriented build system
Home Page: http://erlware.github.com/sinan/
License: MIT License
Erlang/OTP oriented build system
Home Page: http://erlware.github.com/sinan/
License: MIT License
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
Considering the international nature of sinan, it should use the erlang
get_text library to provide multiple language output.
Sinan breaks down when parse transforms are in an included hrl file.
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.
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?
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
What steps will reproduce the problem?
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.
In single app projects the project name and version should not be required in the build config.
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.
What steps will reproduce the problem?
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}]
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.
The release files contain the atom 'load' in the app tuples causing the boot file to be incorrect.
the sinserv process crashes silently and gives a python error to the user if the build config is un parsable. This is non optimal.
Just from reading the documentation, and playing a little with sinan
a few months ago, I have some comments on singen.
$ 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
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.
Useful for local non-production builds (faster)
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.
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?
test
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.
Right now sinan reports missing dependencies one at a time. It should report them all at once.
What steps will reproduce the problem?
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"}]
just run tests in the module that changed
What steps will reproduce the problem?
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.
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
What steps will reproduce the problem?
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?
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.
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.
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}]}}
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
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.
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.
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.
Rebar has a helpful c_src building plugin that folks like. no need not to include similar stuff in sinan.
there should be a pluggable module that you can add to run a build on files of a specified type.
make the _build// look like the standard otp release distributable.
requested by @yrashk
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.
Only print dependency detail in verbose mode
This proper test failed and needs to be resolved
{{'$call',sin_config,remove,[{'','','','','',''},{'$call',sin_config,'add',[{'','','','','',''},0,{'$call',sin_config,new,[]}]}]},{'','','','','','*'},0}
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.
Do this in the same way as rebar
requested by @yrashk
The sinan generated release path should match the OTP version requirements
requested @yrashk
suggested by @yrashk
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.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.