Erlang.mk User Guide

Prev		Next

Chapter 24. Short history

Placeholder chapter.

Prev	Up	Next
	Home

Prev		Next

Chapter 24. Short history

This chapter aims to be a brief record of the life of the +Erlang.mk project.

24.1. Before Erlang.mk

Erlang.mk originates from the Cowboy project. Cowboy started +as a Rebar project and I, Loïc Hoguin, was very happy with it +for a couple years. Over time however I started getting annoyed +and frustrated by a number of things, including bad defaults, +changing defaults and overall slowness.

In particular, at the time I gave up on Erlang.mk, the Cowboy +test suite was taking about five minutes to run. A quick experiment +showed I could get much lower times by simply invoking ct_run +directly. On January 4th, 2013, the Cowboy test suite took less +than a minute to complete.

Following this success I started removing a little more and, +on the fateful day of January 5th, 2013, removed the dependency +on Rebar entirely. Rebar, and in particular the concept of +dependencies, was, and still is, a pretty strong influence.

Erlang.mk was conceived.

A few months passed and, on May 1st, 2013, the Erlang.mk +repository was created. Erlang.mk was born.

Little did I know how much it would grow.

24.2. Lifetime of the project

Erlang.mk would eventually become a much larger file able to +deal with many more projects than just Cowboy. From the birth +of the project, the biggest force for growth was user contributions, +because Erlang.mk appealed to a variety of people with different +needs, needs that Erlang.mk was not fulfilling yet.

The project was split into smaller files focused on a different +feature each, and a build script was written to build the single +Erlang.mk file.

A test suite was contributed by a user, and later taken as a basis +for the current, much more complete test suite. Turns out testing +a Makefile is pretty straightforward.

A package index was added to solve the problem of discovering +Erlang projects.

After trying to see if Erlang build tools could cooperate, the +decision was made to improve compatibility with existing Rebar +projects by patching Rebar out, using Rebar. This feature, called +autopatch, proved very successful and made Erlang.mk compatible +with more than 90% of all Erlang projects.

Erlang.mk documentation was much improved and the Erlang.mk website +was created in the summer of 2015.

Over the year of 2015, Erlang.mk went from curiosity to a serious +alternative to other Erlang build tools. The user base increased +immensely and large projects started using it, including RabbitMQ +from the 3.6.0 release onward.

A bright future lies ahead.

Prev	Up	Next
	Home

Prev		Next

Chapter 25. Architecture

Placeholder chapter.

Prev	Up	Next
	Home

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 +
+Refactoring +
+Features +

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 +should open a ticket as previously explained.

If you have found a bug and you need it to be solved RIGHT +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.

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 +it, you should open a pull request.

Changes need to be tested with at least the make check +command. A specific test case can be tested using make check c=CASE +with CASE the name of the target to run. Output can be +modulated using the V variable, which is an integer +from 0 to 4. A typical use would be make check c=dialyzer V=3. +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.

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
+$ ./pkg_add.sh cowboy git https://github.com/ninenines/cowboy 1.0.0
+  http://ninenines.eu "Small, fast and modular HTTP server."
+$ git push origin master

Before sending a pull request, you should test your package. +You can use the following command: make check p=PACKAGE, +where PACKAGE is the name of the package, for example +cowboy.

To test all packages, the make packages command can be used. +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.

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.

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 +the related documentation.

Prev	Up
	Home

- -

Prev

Chapter 26. Contributing

Placeholder chapter.

Prev	Up
	Home