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

[Michael Truog]

On 04/10/2014 02:17 AM, Benoit Chesneau wrote:
>
>
>
> On Thu, Apr 10, 2014 at 11:05 AM, Michael Truog <mjtruog@REDACTED <mailto:mjtruog@REDACTED>> wrote:
>
>     If you need "rebar generate" behavior in a way that doesn't have extra checks blocking its success and is able to report errors (problems rebar has had in the past), without the logic for windows support, there is a script here:
>     https://github.com/okeuday/reltool_util/blob/master/release
>
>     However, relx should be a better way to go, if you can part with your reltool file.  I haven't found all the reltool options to be supported by relx, so I don't believe it is a fit for all situations.
>
>
> But how do you manage the dependencies?
>
> In a rebar world you're doing:
>
> 1. rebar get-deps
> 2. rebar compile which build deps and what you have in subdirs
> 3. rebar generate which reuses what you fetched in deps etc.
>
> Using erlang.mk <http://erlang.mk>:
>
> 1. fetch the dependeinces using curl and some links you have in a file or such thing
> 2. compile, but not sure if every apps in apps/* are compiled
> 3. use relx or anything else to buld the relese
>
> You can also have 1 make file per app etc.
>
> I am curious how people manage to get the dependencies without rebar or erlang.mk <http://erlang.mk>, build them and then tell to reltools or relx where to find to include them in the release.
>
> IN cloudi it seems for examle that you're using rebar for that. but I can see some projects around publishing their app without any support for rebar. How is it handled behind?
In CloudI (in the main repository) the dependencies are stored locally, and they are modified so that all modules and applications have a 'cloudi_x_' prefix, so that they don't conflict with the same applications running in the same Erlang VM, possibly at a different version.  However, the cloudi_core repository uses rebar to do get-deps without any modification of the modules/application names while limiting it to internal service support.  Both repositories use the rebar compile for building.  I am not trying to say rebar should be used.  I just ended up using rebar due to a lack of better options.

I know erlang.mk exists now, but I also have autoconf/automake which has its own support for Erlang.  Then there is also emake.  I was attempting to use something more automatic and simpler than a makefile, though I know erlang.mk should be simple to use.

Best Regards,
Michael

>
> - benoit
>
>
>
>     On 04/10/2014 12:18 AM, Benoit Chesneau wrote:
>>     Hi all,
>>
>>     I would like to rework the way I am building releases and find a good way to handle the inclusion of dependencies in them. I am generally using the easy path for now by mostly using rebar to get the dependencies but I wonder what others are doing.
>>
>>     How do you get the dependencies, build them and adding them to the release? Are you using your own scripts? Using a makefile like some? In that case how do you maintain the dependencies list and their upgrades?
>>
>>     Any feedback is appreciated :)
>>
>>     - benoit
>>
>>
>>     _______________________________________________
>>     erlang-questions mailing list
>>     erlang-questions@REDACTED  <mailto:erlang-questions@REDACTED>
>>     http://erlang.org/mailman/listinfo/erlang-questions
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140410/aa0e2250/attachment.htm>