I've got a project that uses Rebar as build tool. When developing, I would like all my app dependencies that are specified in Rebar.config be compiled & loaded in the shell as easy as possible. I'm using the Erlang shell in Emacs. What's a quick way to do this?
I'm not using Emacs so I may miss the Emacs-specific side of your question, but when I want an Erlang shell with all my rebar dependencies loaded, I use:
erl -pa ebin deps/*/ebin
./rebar shell
should load all your dependencies.
Related
This may apply to any rebar commands but it is mostly about rebar shell.
By default rebar uses erl and this might be clunky on Windows shells.
According to this source
You can run rebar3 (and any other escript) with werl by specifying the
ESCRIPT_EMULATOR environment variable. In a Git bash that would be:
ESCRIPT_EMULATOR=werl rebar3 shell
Using rebar3 eunit it is able to handle -include("some_file.hrl") in the tests, but this doesn't work with rebar3 ct. For some reason when I use rebar3 ct it tries to compile my eunit tests and fails because it can't find the .hrl files used in the eunit tests. ...can't find include file "some_file.hrl" What am I doing wrong? Why is it compiling eunit tests when I'm trying to run CT tests?
Quick answer:
Additional compile options for eunit. erl_opts can be used like this with rebar3:
{eunit_compile_opts, [
{i, "custominclude"},
{i, "include"},
{i, "deps/nice/include"},
{i, "/usr/lib64/erlang/lib/some-1.3.0/include"}
]}.
https://github.com/erlang/rebar3/blob/fb363cd8de68e9113e407ac0be049cacdd9ddd07/rebar.config.sample#L165
More about this subject
rebar3 change the way eunit tests are performed.
Original rebar2 behavior was to compile your project and anything in the test directory (including subdirectories) to the directory .eunit and then run tests from every file. That's why your include files directive may work under rebar2 simply because all files are included and centralized.
Rebar3 instead, by default, sets Tests to [{application, yourapp}].The eunit command of rebar3 first does some preparation work and after this calls eunit:test(Tests, EUnitOpts).
Notice that:
test sets can be specified via {eunit_tests, [...]} in rebar.config
rebar3 has application, module, file and dir command line flags that mirror the eunit test representations.
http://www.rebar3.org/docs/from-rebar-2x-to-rebar3
Since rebar3 ct will take all this in account, being more configurable and less automated (not including all of your applications and deps) this may happen to you.
I have a number of applications that need a header file to be generated before compilation. This seemed to be a perfect candidate for a Rebar plugin, so I created a plugin with a pre_compile function, put it in a Git repository, and listed it as a dependency in rebar.config in the other applications.
However, the plugin must be compiled before it can be loaded, so when I run rebar compile -v I find that rebar complains about not finding the plugin, then compiles the dependency, and then fails to compile my application because the header file has not been generated.
Is there a way to accomplish what I'm trying to achieve with a Rebar plugin, or do I need to find another way to do it?
The plugin_dir option is your friend:
{plugin_dir, "deps/my_plugin/src"}.
That makes Rebar try to compile the plugin from that source directory if it can't find it in the code path already.
Has anyone worked out an ultra efficient workflow and toolset for Erlang? Debugging, prototyping, browsing, version control, etc.
I'm extremely impressed with Smalltalk's integrated image system, but was wondering if something could be even approaching it with Erlang.
Erlang has a very robust development chain, especially if you are an EMACS maven. There is an Erlang specific build system, there is robust support for packaging your application and its dependencies for deployment and don't forget OTP.
As for tools, there is Dialyzer, real time tracing on running systems, hot code loading ( you can enable and disable or add logging to a running system without restarting it, for example ), remote code execution, there is so much to learn it is dizzying when you start out.
Editor: you can use whatever you want. I used emacs for my first year of erlang, but I'm currently using gedit.
Version Control: I like git. It seems that most of the erlang community agrees (most projects are hosted on github).
Workflow: I'd recommend getting familiar with rebar.
Here is an example of a rebar-flavored Makefile:
REBAR := ./rebar
.PHONY: all deps doc test clean release
all: deps
$(REBAR) compile
deps:
$(REBAR) get-deps
doc:
$(REBAR) doc skip_deps=true
test:
$(REBAR) eunit skip_deps=true
clean:
$(REBAR) clean
release: all test
dialyzer --src src/*.erl deps/*/src/*.erl
Here are some basic pointers:
Put your unit tests in the same modules as the code they are testing. See the rebar wiki for details.
Add {cover_enabled, true} to your rebar.config file. Every time you run make test you get a coverage report in HTML!
Add your project's dependencies to your rebar.config and you can fetch and build them when you run make deps.
Make sure to comment your code with edoc. If you do, rebar can build all of your docs when your run make doc.
I wonder about the difference between Sinan/Faxien and Rebar, too. From my notes, I remember that Sinan/Faxien was more about creating a project template, and dependency management, while Rebar was more useful for creating a module template... My notes are here, are several years old, and are aimed at bootstrapping erlang newbies (like me).
-Todd
I'm having some trouble figuring out how to install Ant on Cygwin. I want to use Ant to build Nutch. I've looked through a bunch of tutorials but I can't find anything that is low level enough for me to understand. I need something like...
Download ant, put it here
Open Cygwin
type "export ANT_HOME=..."
...
Can anyone help me out here?
Assuming you have a JDK already installed, you can do this:
$ export ANT_HOME=/cygdrive/c/apache-ant-1.7.1
which assumes you've unzipped Ant into C:\apache-ant-1.7.1. Then:
$ export PATH=$ANT_HOME/bin:$PATH
$ ant -version
Apache Ant version 1.7.1 compiled on June 27 2008
In Windows, add the path to your ant /bin directory to the Path system variable. This can easily be done by right clicking on Computer > Properties > Advanced System Settings > Environment Variables, click on Path in the System Variables, click on Edit and add ; followed by the path to your ant bin directory to the end of the Variable value.
Start or restart Cygwin.
Type ant -version The version should be displayed.
Here's a step-by-step guide:
simply download and unzip ANT binaries say into c:\apache-ant-1.8.1
download and unzip NUTCH sources say into: c:\apache-nutch-1.2
open the command prompt and run the following:
cd c:\apache-nutch-1.2
c:\apache-ant-1.8.1\bin\ant
the same would work from the Bash shell, just use Cygwin-style paths:
cd /cygdrive/c/apache-nutch-1.2
./cygdrive/c/apache-ant-1.8.1/bin/ant
That's it, you will find a new directory build containing the output.
For convenience, you might want to add the Ant bin directory to the PATH environment variable so that you don't have to give the full path each time, but that's optional.
BTW I just did those exact steps, and all went fine.
Finally, follow this tutorial to get started.