[erlang-questions] how do you build your releases with/without rebar?

Fred Hebert <>
Thu Apr 10 20:22:19 CEST 2014


That's all fine by me too. As I said, the apps/* layout is a layout I'd
love to see get better support overall (I am mostly using rebar, which
does a lot of things halfway for that pattern, and relx, which does it
right).

I'm in no position to tell tool builders what to do or how to write
their code -- I'm free to go around and fix it myself. If erlang.mk
allows to override behavior (you did mention using a top-level makefile
to make things work), that's usually good enough and will let people fix
things the way they need it.

Rebar makes it more complex because of how it builds its list of path
for transient deps (it needs to go down the directories recursively, as
with a 'compile' command or by specifying -r) -- which often conflicts
with running commands within a single directory (apps/ but not deps/).
This is what requires, for CT, calling 'rebar ct -r skip_deps=true',
which is far from obvious.

But I felt like I should defend the directory structure I feel makes the
more sense for release-building, and therefore that I would like to see
love given for from tool builders :)

Regards,
Fred.

On 04/10, Loïc Hoguin wrote:
> Another clarification.
> 
> On 04/10/2014 08:10 PM, Loïc Hoguin wrote:
> >Just want to make sure one thing is clear.
> >
> >On 04/10/2014 07:52 PM, Fred Hebert wrote:
> >>If you end up having to pay that price purely because the build tool you
> >>settled for was opinionated about whether the apps in the apps/ or lib/
> >>directory need to be checked out from other repositories or if they can
> >>be in there already, fix that build tool of yours, because it's
> >>clearly making decisions it should not be making.
> >>
> >>What's more important is that a tool that supports both the apps/* and
> >>the OTP app model can be able to also support *both* of these workflows
> >>(using deps or not to build the release), depending on which is
> >>appropriate for your project, team, and/or community.
> >>
> >>Denying people a way to organize their own workflow because of your
> >>personal opinion when the end result for the files on disk is the exact
> >>same (someone just disagrees about how they ended up there), to me,
> >>tells me that maybe your tool is a bit too opinionated and may need to
> >>take a step back.
> >
> >With regards to erlang.mk, there's nothing to fix. There's nothing it
> >does that prevent you from using the apps/* layout. There's nothing in
> >it that makes it all happen for you either, because that's simply not
> >the goal of the tool. But it can still fit very easily in an apps/*
> >layout, as demonstrated by the gist previously posted. IRCCloud is one
> >such big project that uses both erlang.mk and an apps/* layout, all
> >without any problems AFAIK.
> >
> >erlang.mk will always focus on one OTP application because that's what
> >it's designed to do well. Making it work on two different scopes just
> >makes everything harder, and then you end up with nonsense like "rebar
> >ct compile -r skip_deps=true" (quoting you) to make it do what you want.
> >I do not want that. On the other hand I want to give greater power to
> 
> "I do not want that" refers to supporting the two scopes in erlang.mk
> itself. It is of course very easy to have two different scopes that do
> exactly what you want by simply having one Makefile at the top-level and one
> Makefile for each application. There's nothing preventing you to achieve
> that in a clean manner.
> 
> I will not provide a .mk file for the apps/* layout because I do not use it
> and have no idea what it should do, but I probably would accept a community
> supported "apps/* layout" file in the repository. As long as it's in a
> contrib/ directory or something of course.
> 
> >the user to override or complement the default behavior, and that
> >alongside Windows support is most of the work that remains to be done
> >for erlang.mk 1.0. (Not that you can't change its behavior already -it's
> >a text file after all!- but I want to make it even simpler.)
> >
> >tl;dr Do one thing and do it well; do it right by default but allow
> >overriding its behavior easily.
> 
> -- 
> Loïc Hoguin
> http://ninenines.eu



More information about the erlang-questions mailing list