it is a good thing for all of us that the Erlang eco system is growing!
The problem is that this means that we have more and more options for
building packages. As an application developer If I find a package I
want to use that is written in LFE or Elixir (or whatever new beam
language comes out in 2016) I would like to be able to use it without
having to figure out a new tool.
Since we don't want 1 tool to know how to build everything because that
turns into a nighmare for whomever has to maintain that tool what we
should have is a standard way for a tool to look at a directory and know
how to build it. That way Mix and Rebar (and any other tool) can simply
delegate out building to the correct tool.
If a tool find a package that it does not otherwise know how to build it
should have some standard way to invoke a build
I see that there are a few options for this
1) Use a makefile, even if it is a very simple makefile that simply has
an "all" target that calls mix or rebar
2) have a standard script say ".erl_build" which can be a bash script
that will invoke the actual build tool
Mostly I want this to be simple for both package maintainers, and for
On 12/17/2014 03:38 PM, Zachary Kessin wrote:
> 1) Use a makefile, even if it is a very simple makefile that simply has
> an "all" target that calls mix or rebar
This is what erlang.mk does. It does not care that the dep is written in
Erlang, LFE, or even that it is an Erlang related project. It'll work
even if the dep is a set of JS libs that are minified, or a library
written in C... It just runs "make" on the dep.
Do note that it does not need an "all" target but rather that the result
of running "make" on that Makefile only builds the project (this is
expected behavior of a Makefile). The main target can have any name, it
does not have to be named "all".
Using a Makefile like this also solves the issue that rebar currently
has in that projects are tested against a version of rebar (often
included in the repository) and then that version of rebar is ignored
when building because the top-level rebar builds everything. This means
that if the top-level rebar has a regression (or an unfortunate "fix")
your project may not build when used as a dep.
The side effect of doing it this way for rebar however is that rebar
becomes even slower than it already is as you now have to start the
Erlang VM and rebar many times and this takes a lot of time.
Note that I say rebar here, because it's what I used in the past, but it
probably applies to similar tools in the other languages.