In my project, i want to use mysql so i checkout this https://github.com/dizzyd/erlang-mysql-driver. I want to know how install the application so that my project can interact with it
Have a look at "rebar" - https://bitbucket.org/basho/rebar/wiki/Home
It can be used for installing dependencies, and for creating independent releases.
And a quick look at erlang-mysql-driver, that you want to use, shows that it is also using rebar for its dependency management.
rebar may complicate things if you have already started laying out your app (done some coding already) or if you are a newbie , however, if your project is an erlang/OTP app, then i suggest that you first organize you code according to the recommended file system like this:
MyProject--/src
/ebin
/lib
/include
/priv
/doc
/examples
/test
/Emakefile
The Emakefile is an important file. It maynot have a file extension. It enables the BIF: make:all() to compile all the erlang source modules you point it to and transfers all the .beam files to the destination you want.
For example: is i want all the modules in src to be compiled and transfer the beam files into ebin, i enter this into the Emakefile
{"src/*", [debug_info, netload,strict_record_tests,warn_obsolete_guard,{outdir, "ebin"}]}.
In that case i would start the erlang shell with its pwd() pointing in the folder MyProject, to enable the function call make:all() to find the file Emakfile so as to compile all my src files.
Now, suppose you have another OTP app which you want to have as an extra package in your build. If it OTP-like arranged as i have showed you, and not yet built i.e. not yet made, i mean with only its src and its folder ebin are empty or it ebin may be containing a .APP file already. Then you copy this OTP application into your lib folder, so that your application looks like this:
MyProject--/src
/ebin
/lib/some_otp_app-1.0
/include
/priv
/doc
/examples
/test
/Emakefile
then we would change our Emakefile to look like this:
{"src/*", [debug_info, netload,strict_record_tests,warn_obsolete_guard,{outdir, "ebin"}]}.
{"lib/some_otp_app-1.0/src/*", [debug_info, netload,strict_record_tests,warn_obsolete_guard,{outdir, "lib/some_otp_app-1.0/ebin"}]}.
In the folder MyProject, you can put a shell script that will start your project and add all relevant ebin paths to your nodes code path.the sh script may look like this:
#!/bin/bash
erl \
-name my_node#my_domain \
-pa ./ebin ./lib/*/ebin ./include \
-mnesia dump_log_write_threshold 10000 \
-eval "make:all()"
You can save this file as start_project.sh. Hence as you make changes to your source code, even at the time of starting your project, when you run the sh script with your terminal path pointing into the folder: MyProject, you do this:
$pwd
/export/home/your_user_name/MyProject
$sh start_project.sh
This would start your project at the node you entered in the script and would compile all src files which were changed when it was off. Not only this, you can as well call: make:all() in your shell whenever you make cahnges to your src code. then you would call: l(some_module) after making so that the erlang vm reloads the new object code of the compiled module.
So, your entire project will now appear like this:
MyProject--/src
/ebin
/lib/some_otp_app-1.0
/include
/priv
/doc
/examples
/test
/Emakefile
/start_project.sh
So if you substitute the erlang driver for mysql application with this "some_otp_app-1.0", everything will be fine. success!
Related
I would like to download easylogging++ package, extract the content and then directly use easylogging++.h and easylogging++.cc in my sources.
I started with this:
ExternalProject_Add(
easyloggingpp
PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/downloads
URL https://github.com/muflihun/easyloggingpp/archive/v9.96.4.tar.gz
INSTALL_COMMAND mkdir -p ${CMAKE_CURRENT_BINARY_DIR}/external/easyloggingpp && cp src/easyloggingpp-9.96.4/src/* ${CMAKE_CURRENT_BINARY_DIR}/external/easyloggingpp/)
include_directories(${CMAKE_CURRENT_BINARY_DIR}/external/easyloggingpp)
set(easylogging ${CMAKE_CURRENT_BINARY_DIR}/external/easyloggingpp/easylogging++.cc)
..
add_dependencies(myproject easyloggingpp)
This creates downloads/ directory in my project, but it's empty and no files appear in external/ directory, even the directory itself is not created.
How can I achieve downloading this package and directly merging its sources with mine? I would like to achieve something similar to bazel's new_http_archive.
It seems that ExternalProject_Add is not for the use case I am trying to implement. It looks like the download is only executed during compilation step, not the configuration step. That's a bummer.
I was able to achieve similar result by coding this manually and it works fairly well:
file(MAKE_DIRECTORY downloads external)
################################################################################
# Easylogging++
################################################################################
if(EXISTS "external/easyloggingpp")
else()
file(MAKE_DIRECTORY external/easyloggingpp)
file(DOWNLOAD
https://github.com/muflihun/easyloggingpp/archive/v9.96.4.zip
downloads/easyloggingpp.zip)
execute_process(COMMAND unzip downloads/easyloggingpp.zip -d downloads)
file(GLOB easyloggingpp_files downloads/easyloggingpp-9.96.4/src/easylogging++.*)
file(COPY ${easyloggingpp_files} DESTINATION external/easyloggingpp)
endif()
include_directories(external/easyloggingpp)
set(easyloggingpp external/easyloggingpp/easylogging++.cc)
This works perfectly fine for me and I adtually understand what is happening during the process. The cool things are that cmake . step doesn't download unless it is necessary.
I have cloned and built the waf script using:
./waf-light configure
Then to build my project (provided by Gomspace) I need to add waf and the eclipse.py to my path. So far I haven't found better than this setenv script:
WAFROOT=~/git/waf/
export PYTHONPATH=$WAFROOT/waflib/extras/:$PYTHONPATH
export PATH=~/git/waf/:$PATH
Called with:
source setenv
This is somehow a pretty ugly solution. Is there a more elegant way to install waf?
You don't install waf. The command you found correctly builds waf: /waf-light configure build Then for each project you create, you put the built waf script into that projects root directory. I can't find a reference, but this is the way in which waf:s primary author Thomas Nagy wants the tool to be used. Projects that repackage waf to make the tool installable aren't "officially sanctioned."
There are advantages and disadvantages with non-installation:
Disadvantages:
You have to add the semi-binary 100kb large waf file to your repository.
Because the file contains binary code, people can have legal objections to distributing it.
Advantages:
It doesn't matter if new versions of waf break the old API.
Users don't need to install waf before compiling the project -- having Python on the system is enough.
Fedora (at least Fedora 22) has a yum package for waf, so you could see that it's possible to do a system install of waf, albeit with a hack.
After you run something like python3 ./waf-light configure build, you'll get a file called waf that's actually a Python script with some binary data at the end. If you put it into /usr/bin and run it as non-root, you'll get an error because it fails to create a directory in /usr/bin. If you run it as root, you'll get the new directory and /usr/bin/waf runs normally.
Here's the trick that I learned from examining the find_lib() function in the waf Python script.
Copy the waf to /usr/bin/waf
As root, run /usr/bin/waf. Notice that it creates a directory. You'll see something like /usr/bin/.waf-2.0.19-b2f63c807a4215294bf6005410c74c18
mv that directory to /usr/lib, dropping the . in the directory name, e.g. mv /usr/bin/.waf-2.0.19-b2f63c807a4215294bf6005410c74c18 /usr/lib/waf-2.0.19-b2f63c807a4215294bf6005410c74c18
If you want to use waf with Python3, repeat Steps 2-3 running the Python script /usr/bin/waf under Python3. Under Python3, the directory names will start with .waf3-/waf3- instead instead of .waf-/waf-.
(Optional) Remove the binary data at the end of /usr/bin/waf.
Now, non-root should be able to just use /usr/bin/waf.
That said, here's something to consider, like what another answer said: I believe waf's author intended waf to be embedded in projects so that each project can use its own version of waf without fear that a project will fail to build when there are newer versions of waf. Thus, the one-global-version use case seems to be not officially supported.
Compiled and installed ejabberd version 15.10 on ubuntu 14.04 machine in /opt/ejabberd directory.
In the older version the module can be compiled directly with erlc command and then pasted to ejabberd module dir(or symbolic linked) which was very efficent way to develop the modules.
But after upgrading to newer ejabberd version when using the INFO_MSG()/2 from logger.hrl the ejabberd fails to load the module.
When compiled by placing the module file inside the ejabberd src directory and running make in ejabberd directory as suggested at https://www.ejabberd.im/ejabberd-13.10 and ejabberd how to compile new module the module works.
But this is very inefficient compared to the older method of compiling and running the modules with elrc command directly.
Is the latter approach the right method, if so why was it changed and where are the official docs that explain compiling with latter approach.
you can compile ejabberd module like this
erlc -I /lib/ejabberd/include -o /lib/ejabberd/ebin /home/sunil/Documents/ejabberd_custom_modules/mod_profile.erl
In this example /lib/ejabberd/include is header file (.hrl) path , /lib/ejabberd/ebin* is binary file path of ejabberd and '/home/sunil/Documents/ejabberd_custom_modules/mod_profile.erl is source file path.
Right way to compile your custom ejabberd module (suggested by process-one) is :-
put your module into ejabberd/src folder.
come to ejabberd directory in terminal and run command $ sudo make
it will show you that your module is compiled. You can check ebin directory for .beam file that is result of your compilation.
Now to run your module
$ sudo make install
Add your module into config file at /etc/ejabberd/ejabberd.yml
restart your ejabberd and your custom module will be running.
Another way of compiling with erlang shell is :-
start your erlang to load all included files required by ejabberd module from ebin directory.
> erl -pa <your path to ejabberd/ebin>
You can also give multiple paths separated by space if you are including files from multiple places. Like
> erl -pa <path1/ebin> <path2/ebin>
This will start erlang shell. Next things you need to do are :-
do
> cd("<path to your module.erl file>").
compile your module
> c(your module).
Your module.beam file will be generated as a result of your compilation.
I am using Common Test for code coverage analysis in my erlang project.
File structure
myProject/
ebin/
src/
test/
myProject.coverspec
The .beam-files for the source code is located in ebin/ and for the tests they are in test/ together with the test sources.
I am currently using absolute paths to the .beam files in the .coverspec-file.
myProject.coverspec:
{level,details}.
{incl_dirs, ["/home/user/myProject/ebin", "/home/user/myProject/test"]}.
This works, but is far from optimal as the project development is distributed.
ct_run is called from the base of the project, myProject, the paths don't seem to be relative to myProject but somewhere else.
I've tried paths relative to both myProject and myProject/test w/o success.
My question is, where are the paths in myProject.coverspec relative to?
In my last Erlang project where I have used CT and cover my setup looked like this:
cover.spec in project root directory:
{incl_dirs, ["apps/application_manager/ebin", "apps/session_counter/ebin", "apps/session_heartbeat/ebin", "apps/session_api/ebin"]}.
Tests executed from project root via;
ct_run -pa apps/*/ebin -pa deps/*/ebin -dir apps/*/test/ -logdir tests -- cover cover.spec
Not sure if this solves your problem but it worked for me.
I have an Erlang application (for now just a few library modules) bundled up under Rebar. Directory structure looks like this:
MyProject
- apps
-- myapp
--- ebin
--- src
--- yada
- rebar
- rebar.conf
MyProject$ ./rebar compile responds as expected.
I open up the Erlang shell ( MyProject$ erl -pa apps/*/ebin myapp ) and can execute exported function just fine.
Now I edit a source file, add an exported function, and recompile. But, whaaa--- when I try to execute my new exported function, I get an error--- undefined function. I execute myAppModule:module_info/0 in the Erlang shell. It doesn't list the new function I'd just added to my source file, nor changes I'd made to other functions.
I delete relevant *.beam file and recompile. Still can't see my changes.
But, now I q() out of the Erlang shell and re-enter. What do you know! All works fine, including my new function.
Why should this be?
How do you recompile? From the shell or how?
Note that if you recompile the file "outside" of the executing erlang then you will explicitly have to reload the module (with a l(myAppModule).) in the shell. If you recompile from the shell (with a c(myAppModule).) then the module will be recompiled and reloaded but the .beam file will not be put in the ebin directory but will be in the current working directory.