I'm attempting to use rebar to generate a node, and I've followed the instructions from here.
Running rebar get-deps compile works fine, but running rebar generate gives me
ERROR: Unable to generate spec: read file info /home/inaimathi/common/rebar.config~ failed
ERROR: Unexpected error: rebar_abort
ERROR: generate failed while processing /home/inaimathi/common/rel: rebar_abort
Odd, given that rebar.config~ shouldn't figure anywhere in the generate process. Removing rebar.config~ and trying again gives me the same error, but relating to rebar.config instead.
My rebar.config looks like
{sub_dirs, ["rel"]}.
{lib_dirs, ["deps"]}.
{deps, [{erlsha2, ".*", {git, "git://github.com/vinoski/erlsha2.git", "HEAD"}}]}.
and my reltool.config looks like
{sys, [
{lib_dirs, []},
{erts, [{mod_cond, derived}, {app_file, strip}]},
{app_file, strip},
{rel, "common", "1",
[
kernel,
stdlib,
sasl,
common
]},
{rel, "start_clean", "",
[
kernel,
stdlib
]},
{boot_rel, "common"},
{profile, embedded},
{incl_cond, derived},
{mod_cond, derived},
{excl_archive_filters, [".*"]}, %% Do not archive built libs
{excl_sys_filters, ["^bin/.*", "^erts.*/bin/(dialyzer|typer)",
"^erts.*/(doc|info|include|lib|man|src)"]},
{excl_app_filters, ["\.gitignore"]},
{app, common, [{mod_cond, app}, {incl_cond, include}, {lib_dir, ".."}]}
]}.
{target_dir, "common"}.
{overlay, [
{mkdir, "log/sasl"},
{copy, "files/erl", "\{\{erts_vsn\}\}/bin/erl"},
{copy, "files/nodetool", "\{\{erts_vsn\}\}/bin/nodetool"},
{copy, "files/common", "bin/common"},
{copy, "files/common.cmd", "bin/common.cmd"},
{copy, "files/start_erl.cmd", "bin/start_erl.cmd"},
{copy, "files/install_upgrade.escript", "bin/install_upgrade.escript"},
{copy, "files/sys.config", "releases/\{\{rel_vsn\}\}/sys.config"},
{copy, "files/vm.args", "releases/\{\{rel_vsn\}\}/vm.args"}
]}.
(entirely rebar-generated except that I had to add {lib_dir, ".."} as per the instructions I linked).
What am I doing wrong?
EDIT: I should mention the basics, given that I have no idea what's going wrong. Erlang R15B01 out of the Debian Wheezy repo running on a 64-bit core i3. I did a manual pull and build of rebar from the basho repo. Not sure if anything else is relevant.
EDIT2: The same thing happens with the pre-built version of rebar found at https://github.com/downloads/basho/rebar/rebar
You should have run the rebar generate command in the rel directory before this issue, it is fixed now.
Related
I'm trying to add swagger to an existing demo project erlang_rest_api as a learning experience, but I don't seem to be getting very far...
I cloned the repos:
git clone https://github.com/dronowar/erlang_rest_api
Then I added cowboy_swagger to rebar.config:
{cowboy_swagger, ".*", {git, "git://github.com/inaka/cowboy_swagger.git"}}
And when I build I get:
Dependency not available: jsx-2.9.0 (undefined)
Dependency not available: cowboy-2.5.0 (undefined)
Dependency not available: ranch-1.6.2 (undefined)
Dependency not available: trails-2.1.0 (undefined)
So I add to rebar.config:
{jsx, ".*", {git, "git://github.com/talentdeficit/jsx.git", {tag, "2.9.0"}}},
{ranch, ".*", {git, "git://github.com/ninenines/ranch.git", {tag, "1.6.2"}}},
{trails, ".*", {git, "git://github.com/inaka/cowboy-trails.git", {tag, "2.1.0"}}},
And then I delete the deps directory and build again:
...
==> poolboy (get-deps)
==> sync (get-deps)
==> katana_test (get-deps)
==> jsx (get-deps)
ERROR: Failed to load erlang_rest_api/deps/trails/rebar.config: {error,
{34,
file,
{error,
function_clause,
[{erl_eval,
'-inside-an-interpreted-fun-',
[katana_test],
[]},
{erl_eval,
eval_fun,
6,
[{file,
"erl_eval.erl"},
{line,
829}]},
{erl_eval,
expr_list,
6,
[{file,
"erl_eval.erl"},
{line,
888}]},
{erl_eval,
expr,
5,
[{file,
"erl_eval.erl"},
{line,
240}]},
{erl_eval,
expr_list,
6,
[{file,
"erl_eval.erl"},
{line,
888}]},
{erl_eval,
expr,
5,
[{file,
"erl_eval.erl"},
{line,
240}]},
{erl_eval,
eval_lc1,
6,
[{file,
"erl_eval.erl"},
{line,
706}]},
{erl_eval,
eval_generate,
7,
[{file,
"erl_eval.erl"},
{line,
735}]}]}}}
make: *** [Makefile:7: deps] Error 1
katana_test seems to be some kind of testing tool. I tried adding that repos (inaka/katana-est) to rebar.config but it's not working, either.
I also tried tagging cowboy as version "2.5.0" as listed in "undefined" earlier, but that made no difference.
Do we really need to this specific, listing every dependent repository of every dependency?
I also tried using hex instead:
{jsx, ".*"},
{ranch, ".*"},
{trails, ".*"},
{cowboy_swagger, "2.1.0"}
but I still got:
Dependency not available: jsx-.* (undefined)
Dependency not available: trails-.* (undefined)
Dependency not available: cowboy_swagger-2.1.0 (undefined)
ERROR: compile failed while processing
Am I missing another dependency?
The problem arises from the fact that cowboy_swagger is built to be used with rebar3 and it's not compatible with the old rebar, but erlang_rest_api is using the old rebar, as you can see in its Makefile.
The solution to your problem may be as simple as using rebar3 to build the project. But careful if you do that since that would break make run and make run-local. You'll have to figure out how to achieve the same results using releases.
I set-up some dependencies in my rebar.config (which I have done previously in other projects)
rebar.config:
{sub_dirs, ["sbin", "priv"]}.
{lib_dirs, ["deps/erlang"]}.
{erl_opts, [{parse_transform, lager_transform}]}.
{eunit_opts, [verbose, {report,{eunit_surefire,[{dir,"."}]}}]}.
{cover_enabled, true}.
{cover_export_enabled, true}.
{deps, [
{lager, "2.0.3",
{git, "git://github.com/basho/lager.git", {tag, "2.0.3"}}},
{ezk, ".*",
{git, "git#github.com:campanja/ezk.git"}}
]}.
When I run rebare get-deps I am getting the following errors:
ERROR: Dependency dir /Users/me/workspace/erlang/try-ezk/deps/ezk failed application validation with reason:
{missing_app_file,"/Users/me/workspace/erlang/try-ezk/deps/ezk"}.
ERROR: 'get-deps' failed while processing /Users/me/workspace/erlang/try-ezk: rebar_abort
I'm really not sure what I'm doing wrong this time. Any help would be greatly appreciated.
did you try with this syntax:
{ezk, ".*",{git, "git://github.com/campanja/ezk.git"}}
I've been trying to set up a simple Erlang app using Rebar but can't get it to work. I followed the instructions on http://skeptomai.com/?p=56 to the letter, and when I run ./rebar -v generate, I get this error:
==> Entering directory `/home/adam/erlang-test3/testing-rebar/apps/myapp'
WARN: 'generate' command does not apply to directory /home/adam/erlang-test3/testing-rebar/apps/myapp
==> Leaving directory `/home/adam/erlang-test3/testing-rebar/apps/myapp'
==> Entering directory `/home/adam/erlang-test3/testing-rebar/rel'
==> rel (generate)
{"init terminating in do_boot","Release mynode uses non existing application mynode"}
Crash dump was written to: erl_crash.dump
init terminating in do_boot (Release mynode uses non existing application mynode)
I get a similar error when following https://bitbucket.org/basho/rebar/wiki/ReleaseHandling. When following http://www.metabrew.com/article/erlang-rebar-tutorial-generating-releases-upgrades, I get:
{"init terminating in do_boot",{undef,[{dummy_proj,start,[]},{init,start_it,1},{init,start_em,1}]}}
How do I get rebar to work? My Erlang version is Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [kernel-poll:false]
I also started to learn erlang + rebar and I had the same problem some time ago and
I suppose you have problem in your reltool.config file
Add path to lib_dirs. I have {lib_dirs, ["../../", "../deps/"]}
Add your app to app list. In my case this is - {app, MY_APP_NAME, [{incl_cond, include}]}
Update:
You have to rename you app. F.e. to erlangtest1.
My working reltool.config
{sys, [
{lib_dirs, ["../../"]},
{erts, [{mod_cond, derived}, {app_file, strip}]},
{app_file, strip},
{rel, "exemplar", "1",
[
kernel,
stdlib,
sasl,
erlangtest1
]},
{rel, "start_clean", "",
[
kernel,
stdlib
]},
{boot_rel, "exemplar"},
{profile, embedded},
{incl_cond, exclude},
{excl_archive_filters, [".*"]}, %% Do not archive built libs
{excl_sys_filters, ["^bin/.*", "^erts.*/bin/(dialyzer|typer)",
"^erts.*/(doc|info|include|lib|man|src)"]},
{excl_app_filters, ["\.gitignore"]},
{app, sasl, [{incl_cond, include}]},
{app, stdlib, [{incl_cond, include}]},
{app, kernel, [{incl_cond, include}]},
{app, erlangtest1, [{incl_cond, include}]}
]}.
{target_dir, "exemplar"}.
{overlay, [
{mkdir, "log/sasl"},
{copy, "files/erl", "\{\{erts_vsn\}\}/bin/erl"},
{copy, "files/nodetool", "\{\{erts_vsn\}\}/bin/nodetool"},
{copy, "files/exemplar", "bin/exemplar"},
{copy, "files/exemplar.cmd", "bin/exemplar.cmd"},
{copy, "files/start_erl.cmd", "bin/start_erl.cmd"},
{copy, "files/install_upgrade.escript", "bin/install_upgrade.escript"},
{copy, "files/sys.config", "releases/\{\{rel_vsn\}\}/sys.config"},
{copy, "files/vm.args", "releases/\{\{rel_vsn\}\}/vm.args"}
]}.
I am trying to run rebar generate to generate a release for an erlang rebar project and getting the following error. Any ideas what I am doing wrong?
./rebar generate
Command 'generate' not understood or not applicable
I am on OSX with erlang version Erlang R14B03 and below is my rebar.conf
{lib_dirs, ["deps"]}.
{sub_dirs, ["rel"]}.
{deps, [
{folsom, ".*", {git, "git://github.com/boundary/folsom", "master"}}
]}.
{require_otp_vsn, "R14|R15"}.
{erl_opts, [
fail_on_warning,
debug_info,
warn_missing_spec
]}.
{clean_files, ["*.eunit", "ebin/*.beam", "rel/graphsom"]}.
{cover_enabled, true}.
{eunit_opts, [verbose, {report, {eunit_surefire, [{dir, "."}]}}]}.
You are getting this error because rebar is unable to find a release. You should check if you have reltool.config somewhere and rebar knows about it.
If no release exists, you can create a new one:
mkdir rel
cd rel
../rebar create-node nodeid=YOUR_NODE_ID
Lastly, you need to tell rebar about the release. In your case, you already have the following added to rebar.config:
{sub_dirs, ["rel"]}.
This should allow the generate command to build a new release.
I'm a beginner with rebar and erlang generally. I was trying to create an erlang release with rebar according to this tutorial: http://www.metabrew.com/article/erlang-rebar-tutorial-generating-releases-upgrades and got stuck at the point of running generated release.
My system is Ubuntu 11.04 64bit, erlang R14B03, installed from sources.
When i'm invoking 'bin/somenode console', I get one of the following errors:
Exec: /home/ghik/Inz/somerel/rel/somenode/erts-5.8.4/bin/erlexec -boot /home/ghik/Inz/somerel/rel/somenode/releases/1/somenode -mode embedded -config /home/ghik/Inz/somerel/rel/somenode/etc/app.config -args_file /home/ghik/Inz/somerel/rel/somenode/etc/vm.args -- console
Root: /home/ghik/Inz/somerel/rel/somenode
{"init terminating in do_boot",{'cannot load',hipe_amd64_encode,get_files}}
Crash dump was written to: erl_crash.dump
init terminating in do_boot ()
Interestingly, each time I run it, different atom is listed instead of 'hipe_amd64_encode', for example: 'hipe_amd64_defuse', 'hipe_amd64_assemble', etc.
I'm guessing erlang is unable to load hipe, but I have no idea why is is trying to load it in the first place. The release contains only one, very simple application dependent only on kernel and stdlib.
For some reason, rebar generates a .rel file with lots of unnecessary applications:
%% rel generated at {2011,9,6} {20,5,48}
{release,{"somenode","1"},
{erts,"5.8.4"},
[{kernel,"2.14.4"},
{stdlib,"1.17.4"},
{sasl,"2.1.9.4"},
{someapp,"1"},
{compiler,"4.7.4",load},
{crypto,"2.0.3",load},
{et,"1.4.3",load},
{gs,"1.5.13",load},
{hipe,"3.8",load},
{inets,"5.6",load},
{mnesia,"4.4.19",load},
{observer,"0.9.9",load},
{public_key,"0.12",load},
{runtime_tools,"1.8.5",load},
{ssl,"4.1.5",load},
{syntax_tools,"1.6.7.1",load},
{tools,"2.6.6.4",load},
{webtool,"0.8.8",load},
{wx,"0.98.10",load}]}.
Why does rebar list soo many applications in the .rel file? And event if it's fine, why doesn't the release start?
Add to reltool.config, the following line:
{app, hipe, [{incl_cond, exclude}]}
First of all, you can try to see what fails during the booting of the VM by adding the arguments init_debug to the VM:
$ erl -init_debug
{progress,preloaded}
{progress,kernel_load_completed}
{progress,modules_loaded}
{start,heart}
{start,error_logger}
{start,application_controller}
{progress,init_kernel_started}
...
{progress,applications_loaded}
{apply,{application,start_boot,[kernel,permanent]}}
{apply,{application,start_boot,[stdlib,permanent]}}
{apply,{c,erlangrc,[]}}
{progress,started}
Erlang R14B03 (erts-5.8.4) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:0] [hipe] [kernel-poll:false]
Eshell V5.8.4 (abort with ^G)
1>
Using this, you'll be able to see with more details the kind of interactions going on. It might be that libraries are being loaded in the wrong order, you don't support native, etc.
Second issue, the rel file containing too many applications. This is likely due to the fact that Rebar uses Reltool ot generate releases, and that different applications can be loaded depending on how granular the control is whne generating releases (see incl_cond material in the docs). There are a few examples for this in the Release is The Word chapter of Learn You Some Erlang:
{sys, [
{lib_dirs, ["/home/ferd/code/learn-you-some-erlang/release/"]},
{erts, [{mod_cond, derived}, % derived makes it pick less stuff
{app_file, strip}]},
{rel, "erlcount", "1.0.0", [kernel, stdlib, ppool, erlcount]},
{boot_rel, "erlcount"},
{relocatable, true},
{profile, embedded}, % reduces the files included from each app
{app_file, strip}, % reduces the size of app files if possible
{incl_cond, exclude}, % by default, don't include apps. 'derived' is another option
{app, stdlib, [{mod_cond, derived}, {incl_cond, include}]}, % include at the app
{app, kernel, [{incl_cond, include}]}, % level overrides the
{app, ppool, [{vsn, "1.0.0"}, {incl_cond, include}]}, % exclude put earlier
{app, erlcount, [{vsn, "1.0.0"}, {incl_cond, include}]}
]}.
And this should generate smaller releases.
I don't know the good answer, but I do know that I couldn't start a release running on several CentOS versions with a couple different kernels, so this isn't exactly unusual. Upgrading to 5.6 made it finally work. You can see which OSes actually get tested every day here:
http://www.erlang.org/doc/installation_guide/INSTALL.html#id62915
Also, you could compile without HIPE, I guess.
Lately I found this post:
http://mokele.co.uk/2011/07/01/rebar-release-upgrade-caveats.html
It uncovers a list of errors in rebar, one of them being the reason why my release couldn't launch. There are also fixes published. I hope they will be merged into main rebar repository ASAP.