Geek Answers Handbook

Mochiweb: enable and compile other libraries

My application uses Mochiweb.

I noticed that Mochiweb files are in the myapp/deps/mochiweb , and rebar compile them when I run make in the myapp .

I wanted to add ibrowse to write some tests that make http requests for my application. So I cloned ibrowse from the github directory to myapp/deps/ibrowse .

But it seems that Erlang does not know where to get the .beam files for ibrowse , and therefore all my tests that use the ibrowse module ibrowse not work:

 myapp ebin %%compiled tests reside here, tests which use ibrowse fail (badarg) deps mochiweb ibrowse ebin %%compiled ibrowse module resides here src tests

How can I get my Mochiweb based application to use other external Erlang / OTP libraries?

Should I edit rebar.config or Makefile for this? Or maybe I should edit the _app.src file?

Edit: Perhaps I need to edit the directory listing in myapp_sup.erl? ( myapp_deps:local_path(["priv", "www"] )

PS How does my application know where all the mochiweb.beam files are? (for example, the generic myapp_web.erl uses the mochiweb_http module mochiweb_http , but there is no mochiweb_http.beam myapp/ebin mochiweb_http.beam ).

-one
source share
2 answers

Adding the following code to myapp_web.erl solved my problem:

 ibrowse:start()

By default, Mochiweb runs in the same function:

 mochiweb_http:start()...

I'm not sure if this is the right way to do this, but it works.

0
source

Dependencies in the reinforcement are added via the rebar.config file:

 %% What dependencies we have, dependencies can be of 3 forms, an application %% name as an atom, eg. mochiweb, a name and a version (from the .app file), or %% an application name, a version and the SCM details on how to fetch it (SCM %% type, location and revision). Rebar currently supports git, hg, bzr and svn. {deps, [application_name, {application_name, "1.0.*"}, {application_name, "1.0.*", {git, "git://github.com/basho/rebar.git", {branch, "master"}}}]}.

Then you probably want to take a look at the Erlang releases and handle the rebar release. Think of a release as a way to group applications.

http://www.erlang.org/doc/design_principles/release_handling.html

http://learnyousomeerlang.com/release-is-the-word

https://github.com/basho/rebar/wiki/Release-handling

0
source

More articles:


All Articles