sinan - Project Hosting on Google Code

Older Nov 22, 2009 issue 127 (Couldn't get asn1.tar.gz from repos) reported by Alexander.Wingard - What steps will reproduce the problem? 1. sudo faxien install-release sinan What is the expected output? What do you see instead? Initiating Install for Remote Release sinan-0.16.1.1 Release compiled for R13B01 Pulling down hipe-3.7.2 for R13B01 -> ok Pulling down gs-1.5.10 for R13B01 -> ok Pulling down gtime-0.9.4 for R12B-3 -> ok Pulling down asn1-1.6.10 {unable_to_pull_from_repos,"Couldn't get asn1.tar.gz from repos"} Suggestions: - Couldn't get asn1.tar.gz from repos Please request that the package compiled for your local architecture be published to an accessible repository. - For sasl log information look at "/tmp/faxien.sasl_log" What version of the product are you using? On what operating system? FreeBSD bsd 7.2-STABLE FreeBSD 7.2-STABLE What steps will reproduce the problem? 1. sudo faxien install-release sinan What is the expected output? What do you see instead? Initiating Install for Remote Release sinan-0.16.1.1 Release compiled for R13B01 Pulling down hipe-3.7.2 for R13B01 -> ok Pulling down gs-1.5.10 for R13B01 -> ok Pulling down gtime-0.9.4 for R12B-3 -> ok Pulling down asn1-1.6.10 {unable_to_pull_from_repos,"Couldn't get asn1.tar.gz from repos"} Suggestions: - Couldn't get asn1.tar.gz from repos Please request that the package compiled for your local architecture be published to an accessible repository. - For sasl log information look at "/tmp/faxien.sasl_log" What version of the product are you using? On what operating system? FreeBSD bsd 7.2-STABLE FreeBSD 7.2-STABLE Oct 25, 2009 issue 126 (Sinan should not build releases with apps compiled with vers...) reported by martinjlogan - 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. 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. Sep 15, 2009 issue 125 (Sinan gives cryptic error when failing becuase app name in ....) reported by martinjlogan - 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? 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. Jul 28, 2009 issue 124 (Sinan does not pick up deps on mac) commented on by emofine - One thing I realized that may make my comment a red herring: I upgraded to sinan 0.16.1.1 yesterday. I can't recall if I killed and restarted sinserv or not. I know there is another ticket open for sinserv client checking the version of the server and restarting it if it doesn't match: I think this is a very good idea in general. One thing I realized that may make my comment a red herring: I upgraded to sinan 0.16.1.1 yesterday. I can't recall if I killed and restarted sinserv or not. I know there is another ticket open for sinserv client checking the version of the server and restarting it if it doesn't match: I think this is a very good idea in general. Jul 28, 2009 issue 124 (Sinan does not pick up deps on mac) commented on by emofine - I have the same issue, but on Linux. I build a new version of a library application using sinan dist and then install it using faxien ir. I check the new version is there. Then I do a sinan clean; sinan for an application that is dependent on that app. Sinan picks up the previous version of the library app, not the new one. I kill sinserv and try it again. This time it works and picks up the new library. This is a very critical bug because now I have to check everything to make sure I don't get old code. It has bitten me every now and then from the early days of Sinan onwards. It seems to get fixed and then make its way back somehow. I have the same issue, but on Linux. I build a new version of a library application using sinan dist and then install it using faxien ir. I check the new version is there. Then I do a sinan clean; sinan for an application that is dependent on that app. Sinan picks up the previous version of the library app, not the new one. I kill sinserv and try it again. This time it works and picks up the new library. This is a very critical bug because now I have to check everything to make sure I don't get old code. It has bitten me every now and then from the early days of Sinan onwards. It seems to get fixed and then make its way back somehow. Feb 22, 2009 issue 106 (Forward options to the shell command) commented on by dave.peticolas - I think this issue is now resolved, but in a different way. There is now an --erl-args option which will append all remaining command line arguments to erl. I think this issue is now resolved, but in a different way. There is now an --erl-args option which will append all remaining command line arguments to erl. Jan 16, 2009 issue 124 (Sinan does not pick up deps on mac) reported by martinjlogan - I installed the latest version of GAS on my Mac machine. Running faxien installed confirms that both version 6.1.1 and version 7.0.0 of GAS are on the machine. When I run sinan dist on faxien it fails to pick up the latest version and instead picks up version 6.1.1. This is making it impossible to move forward with development of faxien. This seems to work fine on my linux machine. I installed the latest version of GAS on my Mac machine. Running faxien installed confirms that both version 6.1.1 and version 7.0.0 of GAS are on the machine. When I run sinan dist on faxien it fails to pick up the latest version and instead picks up version 6.1.1. This is making it impossible to move forward with development of faxien. This seems to work fine on my linux machine. Jan 06, 2009 issue 117 (compile_args in _build.cfg does not seem to work) commented on by emofine - Ok, I found that somehow, when sinan was upgraded from 0.11.0.1 to 0.12.0.6, the bin/sinan and bin/sinserv scripts were not changed and still referred to the old 0.11.0.1 release. The problem is in fact solved in 0.12.0.6. There is another issue to do with default_build config compile_args having arguments in common with build.cfg, but it can be worked around (don't have common args) and probably won't affect most people. Ok, I found that somehow, when sinan was upgraded from 0.11.0.1 to 0.12.0.6, the bin/sinan and bin/sinserv scripts were not changed and still referred to the old 0.11.0.1 release. The problem is in fact solved in 0.12.0.6. There is another issue to do with default_build config compile_args having arguments in common with build.cfg, but it can be worked around (don't have common args) and probably won't affect most people. Jan 06, 2009 issue 117 (compile_args in _build.cfg does not seem to work) commented on by emofine - This bug is still present as of version 0.12.0.6 of sinan. I am therefore unable to use needed include directories outside of the actual Sinan application. This is a showstopper that forces me to copy the include files into the application's include directory to get it to compile. This bug is still present as of version 0.12.0.6 of sinan. I am therefore unable to use needed include directories outside of the actual Sinan application. This is a showstopper that forces me to copy the include files into the application's include directory to get it to compile. Dec 08, 2008 issue 123 (sinserv caches out of date dependencies) changed by martinjlogan - Yeah, this is a serious error and needs to be looked at. The good news is we are quite active at the moment so your concern will be looked at. Status: Acknowledged Labels: Type-Defect Priority-High OpSys-All Broken Yeah, this is a serious error and needs to be looked at. The good news is we are quite active at the moment so your concern will be looked at. Status: Acknowledged Labels: Type-Defect Priority-High OpSys-All Broken Dec 08, 2008 issue 123 (sinserv caches out of date dependencies) reported by emofine - 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 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. Dec 08, 2008 issue 122 (sinan does not detect newer install) reported by emofine - What steps will reproduce the problem? 1. Install a newer release 2.0 of package B, on which package A depends. A currently uses rel 1.0 of B. 2. Do a sinan clean and sinan dist of package A. What is the expected output? What do you see instead? Package A distribution STILL contains B 1.0, even though B 2.0 has been published and shown as installed by faxien. Even if I rm -rf _build/. What version of the product are you using? On what operating system? faxien 0.39.0.7 \| 0.35.0.0 sinan 0.12.0.6 Please provide any additional information below. The only way I can overcome this is to completely remove package B (faxien rr) and reinstall it. What steps will reproduce the problem? 1. Install a newer release 2.0 of package B, on which package A depends. A currently uses rel 1.0 of B. 2. Do a sinan clean and sinan dist of package A. What is the expected output? What do you see instead? Package A distribution STILL contains B 1.0, even though B 2.0 has been published and shown as installed by faxien. Even if I rm -rf _build/. What version of the product are you using? On what operating system? faxien 0.39.0.7 \| 0.35.0.0 sinan 0.12.0.6 Please provide any additional information below. The only way I can overcome this is to completely remove package B (faxien rr) and reinstall it. Nov 28, 2008 issue 121 (sinan test ignores the eunit-debugging-macros) reported by DerGraf - 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. 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 Oct 22, 2008 issue 120 (error message for users who don't have >= python 2.5) commented on by dave.peticolas - I just sent a patch that should fix this. I just sent a patch that should fix this. Oct 21, 2008 issue 120 (error message for users who don't have >= python 2.5) commented on by ahmed.nawras - I'm using python 2.3.4 and I get the following error: sinan --help Traceback (most recent call last): File "/opt/erlang/erlware/bin/release_packages/sinan-0.11.0.0/client/sinan", line 93, in ? sys.exit(main()) File "/opt/erlang/erlware/bin/release_packages/sinan-0.11.0.0/client/sinan", line 82, in main {'url' : 'localhost:8599'}) File "/opt/erlang/erlware/release_packages/sinan- 0.11.0.0/client/libsinan/args.py", line 44, in parse parser.add_option("-p", "--prefix", type="str", help=help) File "/usr/lib/python2.3/optparse.py", line 820, in add_option option = self.option_class(args, kwargs) File "/usr/lib/python2.3/optparse.py", line 430, in __init__ checker(self) File "/usr/lib/python2.3/optparse.py", line 499, in _check_type raise OptionError("invalid option type: %r" % self.type, self) optparse.OptionError: option -p/--prefix: invalid option type: 'str' I'm using python 2.3.4 and I get the following error: sinan --help Traceback (most recent call last): File "/opt/erlang/erlware/bin/release_packages/sinan-0.11.0.0/client/sinan", line 93, in ? sys.exit(main()) File "/opt/erlang/erlware/bin/release_packages/sinan-0.11.0.0/client/sinan", line 82, in main {'url' : 'localhost:8599'}) File "/opt/erlang/erlware/release_packages/sinan- 0.11.0.0/client/libsinan/args.py", line 44, in parse parser.add_option("-p", "--prefix", type="str", help=help) File "/usr/lib/python2.3/optparse.py", line 820, in add_option option = self.option_class(args, **kwargs) File "/usr/lib/python2.3/optparse.py", line 430, in __init__ checker(self) File "/usr/lib/python2.3/optparse.py", line 499, in _check_type raise OptionError("invalid option type: %r" % self.type, self) optparse.OptionError: option -p/--prefix: invalid option type: 'str' Oct 18, 2008 issue 117 (compile_args in _build.cfg does not seem to work) commented on by emofine - I sent a patch that fixes this problem, as well as the bug in sin_build_arg_parser.erl. The patch is based on the head branch, so it might not work that well with your dev branch. It must be noted that the _build.cfg file needs to include a section named "tasks" (NOT "task"). Now I don't know if this was always the intention (to use "tasks" instead of "task") so please take a look and see if I did this the right way. Example _build.cfg tasks section: tasks : { build : { compile_args : "+debug_info -Dwhatever" } } I also put back the display of the compile flags, which seemed to have disappeared in the meanwhile from the head. I sent a patch that fixes this problem, as well as the bug in sin_build_arg_parser.erl. The patch is based on the head branch, so it might not work that well with your dev branch. It must be noted that the _build.cfg file needs to include a section named "tasks" (NOT "task"). Now I don't know if this was always the intention (to use "tasks" instead of "task") so please take a look and see if I did this the right way. Example _build.cfg tasks section: tasks : { build : { compile_args : "+debug_info -Dwhatever" } } I also put back the display of the compile flags, which seemed to have disappeared in the meanwhile from the head. Oct 18, 2008 issue 117 (compile_args in _build.cfg does not seem to work) commented on by emofine - I have found the reason for this. It's complicated. The bottom line is that Sinan is using the flavors.development.build.compile_args that are defined in Sinan's priv/default_build file, and ignoring the one in the user's _build.cfg. sinan:do_task/4 calls sin_build_config:start_config/4. In the init([BuildId, ProjectDir, Config, Override]), the key "tasks.build.compile_args" is merged from "flavors.development.build.compile_args", but never overridden by the user's task.build.compile_args. Here's an extract from the config dict (converted to_list). [{"task.build.compile_args","-DFOOBAR +debug_info"}, {"flavors.release.build.compile_args","-DNOTEST=1 -W1"}, {"flavors.development.build.compile_args","+debug_info -W1"}, {"default_flavor","development"} ] The compile_args I want is the one in task.build.compile_args. But the flavors.development.build.compile_args is the one that is used. It looks as if the merging of the dictionaries is not quite right. A workaround is to edit the priv/default_build file and out in the args you like (which will apply to all projects, so it's not necessarily a good workaround). I don't have a patch to correct this at this time. I'm hoping you will know exactly how to fix this in 10 seconds :) Also, there is a bug in sin_build_arg_parser.erl. In an attempt to remove spaces, certain "whitespace" characters are defined, such as $\r, $\n, $\s, $\t and so on. Unfortunately, in a number of places, one of the characters used to define "space" is $\l. This is the lowercase "L" character. I think what was meant was $\f for formfeed or maybe $\v for vertical tab. The effect of this is that any compile_args identifiers that are parsed will lose all lowercase "l" characters, so that "feel_the_love" will become "fee_the_ove". This is easy to reproduce and verify. I have found the reason for this. It's complicated. The bottom line is that Sinan is using the flavors.development.build.compile_args that are defined in Sinan's priv/default_build file, and ignoring the one in the user's _build.cfg. sinan:do_task/4 calls sin_build_config:start_config/4. In the init([BuildId, ProjectDir, Config, Override]), the key "tasks.build.compile_args" is merged from "flavors.development.build.compile_args", but never overridden by the user's task.build.compile_args. Here's an extract from the config dict (converted to_list). [{"task.build.compile_args","-DFOOBAR +debug_info"}, {"flavors.release.build.compile_args","-DNOTEST=1 -W1"}, {"flavors.development.build.compile_args","+debug_info -W1"}, {"default_flavor","development"} ] The compile_args I want is the one in task.build.compile_args. But the flavors.development.build.compile_args is the one that is used. It looks as if the merging of the dictionaries is not quite right. A workaround is to edit the priv/default_build file and out in the args you like (which will apply to all projects, so it's not necessarily a good workaround). I don't have a patch to correct this at this time. I'm hoping you will know exactly how to fix this in 10 seconds :) Also, there is a bug in sin_build_arg_parser.erl. In an attempt to remove spaces, certain "whitespace" characters are defined, such as $\r, $\n, $\s, $\t and so on. Unfortunately, in a number of places, one of the characters used to define "space" is $\l. This is the lowercase "L" character. I think what was meant was $\f for formfeed or maybe $\v for vertical tab. The effect of this is that any compile_args identifiers that are parsed will lose all lowercase "l" characters, so that "feel_the_love" will become "fee_the_ove". This is easy to reproduce and verify. Oct 15, 2008 issue 120 (error message for users who don't have >= python 2.5) commented on by dave.peticolas - What's the actual error message you get? Python2.4 works fine for me. What's the actual error message you get? Python2.4 works fine for me. Oct 13, 2008 issue 120 (error message for users who don't have >= python 2.5) commented on by dave.peticolas - Agreed, but it should be possible to make it work on an even earlier version as well. I'll check it out. Agreed, but it should be possible to make it work on an even earlier version as well. I'll check it out. Oct 13, 2008 issue 120 (error message for users who don't have >= python 2.5) reported by martinjlogan - Sinan needs to provide info to the user saying that they need python 2.5 or greater to run it. Sinan blows up on any lower version with a very confusing error message. Sinan needs to provide info to the user saying that they need python 2.5 or greater to run it. Sinan blows up on any lower version with a very confusing error message. Sep 17, 2008 issue 119 (included applications causes this error when you have dup en...) reported by martinjlogan - I accidentally double entered apps in included apps and applications in my .app file and got this. the formate thing still lives in version 0.11.0.0 Macintosh:vfs_otp martinjlogan$ sinan dist starting run [check_depends] start [check_depends] stop [build] start [build] stop [release] start [sin_release_builder fault!!] undef: [{systools_make,formate_error, [{apps, [{circular_dependencies, [{eunit,"2.0"}, {resource_discovery,"1.0.0"}, {sasl,"2.1.5.3"}]}, {undefined_applications,[gas]}]}]}, {sin_release_builder,make_boot_script,2}, {sin_release_builder,release,1}, {eta_task_runner,execute_task_stack,3}, {eta_task_runner,run_tasks,3}, {eta_task_runner,do_tasks,3}, {eta_task_runner,'-run_task_reply/4-fun-0-',4}, {proc_lib,init_p,3}] Task failed run complete with faults Macintosh:vfs_otp martinjlogan$ faxien ur sinan sinan at version 0.11.0.0 is up to date I accidentally double entered apps in included apps and applications in my .app file and got this. the formate thing still lives in version 0.11.0.0 Macintosh:vfs_otp martinjlogan$ sinan dist starting run [check_depends] start [check_depends] stop [build] start [build] stop [release] start [sin_release_builder fault!!] undef: [{systools_make,formate_error, [{apps, [{circular_dependencies, [{eunit,"2.0"}, {resource_discovery,"1.0.0"}, {sasl,"2.1.5.3"}]}, {undefined_applications,[gas]}]}]}, {sin_release_builder,make_boot_script,2}, {sin_release_builder,release,1}, {eta_task_runner,execute_task_stack,3}, {eta_task_runner,run_tasks,3}, {eta_task_runner,do_tasks,3}, {eta_task_runner,'-run_task_reply/4-fun-0-',4}, {proc_lib,init_p,3}] Task failed run complete with faults Macintosh:vfs_otp martinjlogan$ faxien ur sinan sinan at version 0.11.0.0 is up to date Sep 17, 2008 issue 118 (Enhancement: Show compiler options when building) reported by emofine - 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. 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. Sep 17, 2008 issue 117 (compile_args in _build.cfg does not seem to work) reported by emofine - 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"}] 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"}] Sep 17, 2008 issue 116 (Command-line task override does not work) reported by emofine - 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. 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. Sep 08, 2008 issue 110 (Crash when starting sinan shell) Status changed by cyberlync - Guys, do a 'faxien ir erl'. That will solve your problem. Martin and I are working on doing some release dependency stuff to get rid of this completly. Status: Accepted Guys, do a 'faxien ir erl'. That will solve your problem. Martin and I are working on doing some release dependency stuff to get rid of this completly. Status: Accepted Sep 07, 2008 issue 110 (Crash when starting sinan shell) commented on by phil.larson - I have the same problem. I have the same problem. Sep 06, 2008 issue 115 (~/.sinan/repo not updated when fresh code published) reported by emofine - What steps will reproduce the problem? 1. Publish a release on which an existing, already-built sinan project is dependent. The published release updates an existing one, without changing the release number. 2. Rebuild the sinan project. 3. The changes in the new release just published will not be pulled into the .sinan/repo. What is the expected output? What do you see instead? I expect that if I publish a release on which my project depends, when sinan rebuilds my project, it will detect the change and download the modified release during dependency analysis. What version of the product are you using? On what operating system? sinan 0.11.0.0 on Ubuntu 8.04 x86_64 Please provide any additional information below. Discussed at length with Eric and Martin. Recommended solution by Eric is for faxien to push an MD5 along with a release tarball, and for sinan to check that during dependency analysis. This needs a defect report for faxien, which I will do after this one. What steps will reproduce the problem? 1. Publish a release on which an existing, already-built sinan project is dependent. The published release updates an existing one, without changing the release number. 2. Rebuild the sinan project. 3. The changes in the new release just published will not be pulled into the .sinan/repo. What is the expected output? What do you see instead? I expect that if I publish a release on which my project depends, when sinan rebuilds my project, it will detect the change and download the modified release during dependency analysis. What version of the product are you using? On what operating system? sinan 0.11.0.0 on Ubuntu 8.04 x86_64 Please provide any additional information below. Discussed at length with Eric and Martin. Recommended solution by Eric is for faxien to push an MD5 along with a release tarball, and for sinan to check that during dependency analysis. This needs a defect report for faxien, which I will do after this one. Sep 03, 2008 issue 114 (Sinan needs a function indicating it's erts vsn from the com...) reported by martinjlogan - 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. 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. Aug 01, 2008 issue 113 (sinan gen does not create config nor sys.config) reported by martinjlogan - Sinan gen should create these artifacts. It would also be a good idea to create a bin dir and an executable startup script template. Sinan gen should create these artifacts. It would also be a good idea to create a bin dir and an executable startup script template.

issue 117 (compile_args in _build.cfg does not seem to work) commented on by emofine - I have found the reason for this. It's complicated. The bottom line is that Sinan is using the flavors.development.build.compile_args that are defined in Sinan's priv/default_build file, and ignoring the one in the user's _build.cfg. sinan:do_task/4 calls sin_build_config:start_config/4. In the init([BuildId, ProjectDir, Config, Override]), the key "tasks.build.compile_args" is merged from "flavors.development.build.compile_args", but never overridden by the user's task.build.compile_args. Here's an extract from the config dict (converted to_list). [{"task.build.compile_args","-DFOOBAR +debug_info"}, {"flavors.release.build.compile_args","-DNOTEST=1 -W1"}, {"flavors.development.build.compile_args","+debug_info -W1"}, {"default_flavor","development"} ] The compile_args I want is the one in task.build.compile_args. But the flavors.development.build.compile_args is the one that is used. It looks as if the merging of the dictionaries is not quite right. A workaround is to edit the priv/default_build file and out in the args you like (which will apply to all projects, so it's not necessarily a good workaround). I don't have a patch to correct this at this time. I'm hoping you will know exactly how to fix this in 10 seconds :) Also, there is a bug in sin_build_arg_parser.erl. In an attempt to remove spaces, certain "whitespace" characters are defined, such as $\r, $\n, $\s, $\t and so on. Unfortunately, in a number of places, one of the characters used to define "space" is $\l. This is the lowercase "L" character. I think what was meant was $\f for formfeed or maybe $\v for vertical tab. The effect of this is that any compile_args identifiers that are parsed will lose all lowercase "l" characters, so that "feel_the_love" will become "fee_the_ove". This is easy to reproduce and verify.

I have found the reason for this. It's complicated. The bottom line is that Sinan is using the flavors.development.build.compile_args that are defined in Sinan's priv/default_build file, and ignoring the one in the user's _build.cfg. sinan:do_task/4 calls sin_build_config:start_config/4. In the init([BuildId, ProjectDir, Config, Override]), the key "tasks.build.compile_args" is merged from "flavors.development.build.compile_args", but never overridden by the user's task.build.compile_args. Here's an extract from the config dict (converted to_list). [{"task.build.compile_args","-DFOOBAR +debug_info"}, {"flavors.release.build.compile_args","-DNOTEST=1 -W1"}, {"flavors.development.build.compile_args","+debug_info -W1"}, {"default_flavor","development"} ] The compile_args I want is the one in task.build.compile_args. But the flavors.development.build.compile_args is the one that is used. It looks as if the merging of the dictionaries is not quite right. A workaround is to edit the priv/default_build file and out in the args you like (which will apply to all projects, so it's not necessarily a good workaround). I don't have a patch to correct this at this time. I'm hoping you will know exactly how to fix this in 10 seconds :) Also, there is a bug in sin_build_arg_parser.erl. In an attempt to remove spaces, certain "whitespace" characters are defined, such as $\r, $\n, $\s, $\t and so on. Unfortunately, in a number of places, one of the characters used to define "space" is $\l. This is the lowercase "L" character. I think what was meant was $\f for formfeed or maybe $\v for vertical tab. The effect of this is that any compile_args identifiers that are parsed will lose all lowercase "l" characters, so that "feel_the_love" will become "fee_the_ove". This is easy to reproduce and verify.

Older