Erlang.mk User Guide

Prev		Next

Chapter 19. Continuous integration

Placeholder chapter.

Prev	Up	Next
	Home

Prev		Next

Chapter 18. Continuous integration

Placeholder chapter.

Prev	Up	Next
	Home

Prev

Chapter 26. Contributing

You are welcome and encouraged to contribute.

This is how.

26.1. Priorities

From the most important to the least important:

+
Prev
Chapter 25. Contributing
You are welcome and encouraged to contribute.
This is how.
25.1. Priorities
From the most important to the least important:
- Bugs
- Package issues/additions @@ -41,7 +41,7 @@ Package issues/additions Refactoring
- Features -
26.2. Bugs
If you have found a bug, you should open a ticket. Include +

25.2. Bugs

If you have found a bug, you should open a ticket. Include everything relevant including the command you used, output, a link to the code that triggers the issue, why you think this is a bug, etc.

If you think you have found a bug but you are not sure, you @@ -49,7 +49,7 @@ should open a ticket as previously explained.

If you have found a bug and NOW, open a ticket as previously explained.

Once you have opened a ticket, be patient, try to answer questions in a timely manner and confirm that the bug was indeed fixed when it is.

If you can’t be patient, either try to solve the bug and -contribute the fix back or become a paying customer.

26.3. Code

The code is located in the core/*.mk and plugins/*.mk files. +contribute the fix back or become a paying customer.

25.3. Code

The code is located in the core/*.mk and plugins/*.mk files. The tests are located in the test/Makefile and test/*.mk files.

If you have a fix or a hack for a bug, you should open a pull request. Any fix should include a test case that fails before the fix and is working after.

If you have a test case that reproduces a bug, but no fix for @@ -62,7 +62,7 @@ The value 4 is particular and shows expanded commands right before they are executed.

To run tests in parallel, use the -j option. It is generally a good idea to also use the -k option to run all tests even if one fails. For example: make check -j 32 -k.

Some changes should be tested against all packages. Continue -reading for more details on testing them.

26.4. Packages

You can search existing packages using the make search q=STRING +reading for more details on testing them.

25.4. Packages

You can search existing packages using the make search q=STRING command. This can be done both from an Erlang.mk project or directly from the Erlang.mk repository.

Packages can be added to the index using the pkg_add.sh script.

$ git clone https://github.com/$YOURUSERNAME/erlang.mk
 $ cd erlang.mk
@@ -75,10 +75,10 @@ where PACKAGE is the name of the package, for examp
 This can take a long time. Some packages will fail with certain
 versions of Erlang, or if a prerequisite is missing from your system.
 You can of course speed things up using the -j and -k flags.
After all packages have been tested, you can run the command
-make summary to know what changed since the previous run.

26.5. Documentation

The documentation is always right.

If you think you have found a mistake in the documentation, +make summary to know what changed since the previous run.

25.5. Documentation

The documentation is always right.

If you think you have found a mistake in the documentation, this is a bug. You can either open a ticket or send a pull request.

To make sure that the documentation changes work, install -Asciidoc on your system and run make docs.

26.6. Feature requests

If you have an awesome idea or need something that Erlang.mk +Asciidoc on your system and run make docs.

25.6. Feature requests

If you have an awesome idea or need something that Erlang.mk doesn’t provide yet, open a ticket. Provide as much detail as possible.

If you have code, great! Open a pull request as previously explained.

If not, you can still improve your feature request by writing diff --git a/guide/coverage.html b/guide/coverage.html index 85e94e0..46e1bba 100644 --- a/guide/coverage.html +++ b/guide/coverage.html @@ -33,7 +33,7 @@ div.navfooter{margin-bottom:1em}

Prev		Next

Chapter 18. Code coverage

Placeholder chapter.

Prev	Up	Next
	Home

Prev		Next

Chapter 17. Code coverage

Placeholder chapter.

Prev	Up	Next
	Home

diff --git a/guide/ct.html b/guide/ct.html index b1672f8..2a0a592 100644 --- a/guide/ct.html +++ b/guide/ct.html @@ -33,7 +33,7 @@ div.navfooter{margin-bottom:1em}

Prev		Next

Chapter 16. Common Test

Common Test is Erlang’s functional testing framework. +

Prev		Next

Chapter 16. Common Test

Common Test is Erlang’s functional testing framework. Erlang.mk automates the discovery and running of Common Test suites.

16.1. Writing tests

The Common Test user guide is the best place to learn how to write tests. Erlang.mk @@ -55,9 +55,9 @@ using the variable t. Note that this only applies t suite-specific targets, like the ct-http example above.

To run all tests from the http_compress group in the http_SUITE test suite, write:

$ make ct-http t=http_compress

Similarly, to run a specific test case in that group:

$ make ct-http t=http_compress:headers_dupe

To do the same against a multi-application repository, you can use the -C option:

$ make -C apps/my_app ct-http t=my_group:my_case

Note that this also applies to dependencies. When using Cowboy -as a dependency, you can run the following directly:

$ make -C deps/cowboy ct-http t=http_compress

Finally, code coverage -Chapter 18, Code coverage is available, -but covered in its own chapter.

Prev	Up	Next
	Home

+as a dependency, you can run the following directly:

$ make -C deps/cowboy ct-http t=http_compress

Finally, code coverage +Chapter 17, Code coverage is available, +but covered in its own chapter.

Prev	Up	Next
	Home

Prev		Next

Chapter 20. Dialyzer

Dialyzer is a tool that will detect discrepancies in your +

Prev		Next

Chapter 19. Dialyzer

Dialyzer is a tool that will detect discrepancies in your program. It does so using a technique known as success typing analysis which has the advantage of providing no false positives. Dialyzer is able to detect type errors, -dead code and more.

Erlang.mk provides a wrapper around Dialyzer.

20.1. How it works

Dialyzer requires a PLT file to work. The PLT file contains +dead code and more.

Erlang.mk provides a wrapper around Dialyzer.

19.1. How it works

Dialyzer requires a PLT file to work. The PLT file contains the analysis information from all applications which are not expected to change, or rarely do. These would be all the dependencies of the application or applications you are currently working on, including standard applications in Erlang/OTP itself.

Dialyzer can generate this PLT file. Erlang.mk includes rules to automatically generate the PLT file when it is missing.

Once the PLT file is generated, Dialyzer can perform the -analysis in record time.

20.2. Configuration

In a typical usage scenario, no variable needs to be set. +analysis in record time.

19.2. Configuration

In a typical usage scenario, no variable needs to be set. The defaults should be enough. Do note however that the dependencies need to be set properly using the DEPS and LOCAL_DEPS variables.

The DIALYZER_PLT file indicates where the PLT file will @@ -59,7 +59,7 @@ The former one defines which directories should be part of the analysis. The latter defines what extra warnings Dialyzer should report.

Note that Erlang.mk enables the race condition warnings by default. As it can take considerably large resources -to run, you may want to disable it on larger projects.

20.3. Usage

To perform an analysis, run the following command:

$ make dialyze

This will create the PLT file if it doesn’t exist.

The analysis will also be performed when you run the +to run, you may want to disable it on larger projects.

19.3. Usage

To perform an analysis, run the following command:

$ make dialyze

This will create the PLT file if it doesn’t exist.

The analysis will also be performed when you run the following command, alongside tests:

$ make check

You can use the plt target to create the PLT file if it doesn’t exist. This is normally not necessary as Dialyzer creates it automatically.

The PLT file will be removed when you run make distclean.

Prev	Up	Next
	Home

diff --git a/guide/eunit.html b/guide/eunit.html index 2162fee..2bbeecd 100644 --- a/guide/eunit.html +++ b/guide/eunit.html @@ -70,8 +70,8 @@ the variable t.

For example, to run all tests module (instead of all tests from the entire project), one could write:

$ make eunit t=cow_http_hd

Similarly, to run a specific test case:

$ make eunit t=cow_http_hd:parse_accept_test_

To do the same against a multi-application repository, you can use the -C option:

$ make -C apps/my_app eunit t=my_module:hello_test

Note that this also applies to dependencies. From Cowboy, -you can run the following directly:

$ make -C deps/cowlib eunit t=cow_http_hd

Finally, code coverage -Chapter 18, Code coverage is available, +you can run the following directly:

$ make -C deps/cowlib eunit t=cow_http_hd

Finally, code coverage +Chapter 17, Code coverage is available, but covered in its own chapter.

Prev	Up	Next
	Home

		Next

		Next

Prev		Next

Chapter 23. List of plugins

This is a non-exhaustive list of Erlang.mk plugins, sorted -alphabetically.

23.1. efene.mk

An Efene plugin for Erlang.mk. -Efene is an alternative language for the BEAM.

23.2. elixir.mk

An Elixir plugin for +

Prev		Next

Chapter 22. List of plugins

This is a non-exhaustive list of Erlang.mk plugins, sorted +alphabetically.

22.1. efene.mk

An Efene plugin for Erlang.mk. +Efene is an alternative language for the BEAM.

22.2. elixir.mk

An Elixir plugin for Erlang.mk. Elixir is an alternative -language for the BEAM.

23.3. elvis.mk

An Elvis plugin for Erlang.mk. -Elvis is an Erlang style reviewer.

23.4. geas

Geas gives aggregated +language for the BEAM.

22.3. elvis.mk

An Elvis plugin for Erlang.mk. +Elvis is an Erlang style reviewer.

22.4. geas

Geas gives aggregated information on a project and its dependencies, and is available -as an Erlang.mk plugin.

23.5. hexer.mk

An Hex plugin for Erlang.mk. -Hex is a package manager for the Elixir ecosystem.

23.6. lfe.mk

An LFE plugin for Erlang.mk. +as an Erlang.mk plugin.

22.5. hexer.mk

An Hex plugin for Erlang.mk. +Hex is a package manager for the Elixir ecosystem.

22.6. lfe.mk

An LFE plugin for Erlang.mk. LFE, or Lisp Flavoured Erlang, is an alternative -language for the BEAM.

23.7. reload.mk

A live reload plugin for Erlang.mk.

Prev	Up	Next
	Home

+language for the BEAM.

22.7. reload.mk

A live reload plugin for Erlang.mk.

Prev	Up	Next
	Home

Prev		Next

Chapter 22. External plugins

It is often convenient to be able to keep the build files +

Prev		Next

Chapter 21. External plugins

It is often convenient to be able to keep the build files used by all your projects in one place. Those files could be Makefiles, configuration files, templates and more.

Erlang.mk allows you to automatically load plugins from dependencies. Plugins can do anything, including defining @@ -42,19 +42,19 @@ inside the normal Erlang.mk processing or even adding new rules.

You can load plugins using one of two methods. You can either load all plugins from a dependency, or just one. We will also cover conventions about writing external -plugins.

22.1. Loading all plugins from a dependency

To load plugins from a dependency, all you need to do is add +plugins.

21.1. Loading all plugins from a dependency

To load plugins from a dependency, all you need to do is add the dependency name to DEP_PLUGINS in addition to the list of dependencies.

For example, if you have cowboy in DEPS, add cowboy in DEP_PLUGINS also:

DEPS = cowboy
 DEP_PLUGINS = cowboy

This will load the file plugins.mk in the root folder of -the Cowboy repository.

22.2. Loading one plugin from a dependency

Now that we know how to load all plugins, let’s take a look +the Cowboy repository.

21.2. Loading one plugin from a dependency

Now that we know how to load all plugins, let’s take a look at how to load one specific plugin from a dependency.

To do this, instead of writing only the name of the dependency, we will write its name and the path to the plugin file. This means that writing DEP_PLUGINS = cowboy is equivalent to writing DEP_PLUGINS = cowboy/plugins.mk.

Knowing this, if we were to load the plugin mk/dist.mk from Cowboy and no other, we would write the following in our Makefile:

DEPS = cowboy
-DEP_PLUGINS = cowboy/mk/dist.mk

22.3. Writing external plugins

The plugins.mk file is a convention. It is meant to load +DEP_PLUGINS = cowboy/mk/dist.mk

21.3. Writing external plugins

The plugins.mk file is a convention. It is meant to load all the plugins from the dependency. The code for the plugin can be written directly in plugins.mk or be separate.

If you are providing more than one plugin with your repository, the recommended way is to create one file per plugin in the diff --git a/guide/property_based_testing.html b/guide/property_based_testing.html deleted file mode 100644 index cc58b10..0000000 --- a/guide/property_based_testing.html +++ /dev/null @@ -1,39 +0,0 @@ - - - - -Erlang.mk User Guide - - - -

- -

Prev		Next

Chapter 17. Property based testing

Placeholder chapter.

Prev	Up	Next
	Home

- - diff --git a/guide/why.html b/guide/why.html index 5dfa60e..925063c 100644 --- a/guide/why.html +++ b/guide/why.html @@ -33,15 +33,15 @@ div.navfooter{margin-bottom:1em}

Prev		Next

Chapter 24. Why Erlang.mk

Why would you choose Erlang.mk, if not for its +

Prev		Next

Chapter 23. Why Erlang.mk

Why would you choose Erlang.mk, if not for its many features Chapter 3, Overview? This chapter will -attempt to answer that.

24.1. Erlang.mk is fast

Erlang.mk is as fast as it gets.

Erlang.mk will group the compilation of files so as to avoid +attempt to answer that.

23.1. Erlang.mk is fast

Erlang.mk is as fast as it gets.

Erlang.mk will group the compilation of files so as to avoid running the BEAM more than necessary. This saves many seconds compared to traditional Makefiles, even on small projects.

Erlang.mk will not try to be too smart. It provides a simple solution that works for most people, and gives additional options for projects that run into edge cases, often in the -form of extra variables or rules to be defined.

24.2. Erlang.mk gives you the full power of Unix

Erlang.mk is a Makefile.

You could use Erlang.mk directly without configuring anything +form of extra variables or rules to be defined.

23.2. Erlang.mk gives you the full power of Unix

Erlang.mk is a Makefile.

You could use Erlang.mk directly without configuring anything and it would just work. But you can also extend it greatly either through configuration or hooks, and you can of course add your own rules to the Makefile.

In all cases: for configuration, hooks or custom rules, you @@ -49,22 +49,22 @@ have all the power of Unix at your disposal, and can call any utility or even any language interpreter you want, every time you need to. Erlang.mk also allows you to write scripts in this small language called Erlang directly inside -your Makefile if you ever need to…

24.3. Erlang.mk is a text file

Erlang.mk is a Makefile.

Which means Erlang.mk is a simple text file. You can edit a +your Makefile if you ever need to…

23.3. Erlang.mk is a text file

Erlang.mk is a Makefile.

Which means Erlang.mk is a simple text file. You can edit a text file. Nothing stops you. If you run into any bug, or behavior that does not suit you, you can just open the erlang.mk file in your favorite editor, fix and/or comment -a few lines, save, and try again. It’s as simple as it gets.

Currently using a binary build tool? Good luck with that.

24.4. Erlang.mk can manage Erlang itself

Erlang.mk isn’t written in Erlang.

That’s not a good thing, you say? Well, here’s one thing +a few lines, save, and try again. It’s as simple as it gets.

Currently using a binary build tool? Good luck with that.

23.4. Erlang.mk can manage Erlang itself

Erlang.mk isn’t written in Erlang.

That’s not a good thing, you say? Well, here’s one thing that Erlang.mk and Makefiles can do for you that Erlang build tool can’t easily: choose what version of Erlang is to be used for compiling the project.

This really is a one-liner in Erlang.mk (a few more lines if you also let it download and build Erlang directly) and allows for even greater things, like testing your project across all supported Erlang versions in one small -command: make -k ci.

24.5. Erlang.mk can do more than Erlang

Erlang.mk doesn’t care what your dependencies are written in.

Erlang.mk will happily compile any dependency, as long as +command: make -k ci.

23.5. Erlang.mk can do more than Erlang

Erlang.mk doesn’t care what your dependencies are written in.

Erlang.mk will happily compile any dependency, as long as they come with a Makefile. The dependency can be written in C, C++ or even Javascript… Who cares, really? If you need Erlang.mk to fetch it, then Erlang.mk will fetch it -and compile it as needed.

24.6. Erlang.mk integrates nicely in Make and Automake projects

If you are planning to put your project in the middle of +and compile it as needed.

23.6. Erlang.mk integrates nicely in Make and Automake projects

If you are planning to put your project in the middle of a Make or Automake-based build environment, then the most logical thing to do is to use a Makefile.

Erlang.mk will happily sit in such an environment and behave as you expect it to.

Prev	Up	Next
	Home

diff --git a/guide/xref.html b/guide/xref.html index 4d0bc06..acc4209 100644 --- a/guide/xref.html +++ b/guide/xref.html @@ -33,7 +33,7 @@ div.navfooter{margin-bottom:1em}

Prev		Next

Chapter 21. Xref

Placeholder chapter.

Prev	Up	Next
	Home

Prev		Next

Chapter 20. Xref

Placeholder chapter.

Prev	Up	Next
	Home

-- cgit v1.2.3

Chapter 19. Continuous integration

Chapter 18. Continuous integration

Chapter 26. Contributing

26.1. Priorities

Chapter 25. Contributing

25.1. Priorities

26.2. Bugs

25.2. Bugs

26.3. Code

25.3. Code

26.4. Packages

25.4. Packages

26.5. Documentation

25.5. Documentation

26.6. Feature requests

25.6. Feature requests

Chapter 18. Code coverage

Chapter 17. Code coverage

Chapter 16. Common Test

Chapter 16. Common Test

16.1. Writing tests

Chapter 20. Dialyzer

Chapter 19. Dialyzer

20.1. How it works

19.1. How it works

20.2. Configuration

19.2. Configuration

20.3. Usage

19.3. Usage

Chapter 25. Short history

25.1. Before Erlang.mk

Chapter 24. Short history

24.1. Before Erlang.mk

25.2. Lifetime of the project

24.2. Lifetime of the project

Erlang.mk User Guide

Loïc Hoguin

Erlang.mk User Guide

Loïc Hoguin

3.5. Need more?

3.5. Need more?

Chapter 23. List of plugins

23.1. efene.mk

23.2. elixir.mk

Chapter 22. List of plugins

22.1. efene.mk

22.2. elixir.mk

23.3. elvis.mk

23.4. geas

22.3. elvis.mk

22.4. geas

23.5. hexer.mk

23.6. lfe.mk

22.5. hexer.mk

22.6. lfe.mk

23.7. reload.mk

22.7. reload.mk

Chapter 22. External plugins

Chapter 21. External plugins

22.1. Loading all plugins from a dependency

21.1. Loading all plugins from a dependency

22.2. Loading one plugin from a dependency

21.2. Loading one plugin from a dependency

22.3. Writing external plugins

21.3. Writing external plugins

Chapter 17. Property based testing

Chapter 24. Why Erlang.mk

Chapter 23. Why Erlang.mk

24.1. Erlang.mk is fast

23.1. Erlang.mk is fast

24.2. Erlang.mk gives you the full power of Unix

23.2. Erlang.mk gives you the full power of Unix

24.3. Erlang.mk is a text file

23.3. Erlang.mk is a text file

24.4. Erlang.mk can manage Erlang itself

23.4. Erlang.mk can manage Erlang itself

24.5. Erlang.mk can do more than Erlang

23.5. Erlang.mk can do more than Erlang

24.6. Erlang.mk integrates nicely in Make and Automake projects

23.6. Erlang.mk integrates nicely in Make and Automake projects