[erlang-questions] Fwd: mysterious reltool exception

[Tim Watson]

On 17 November 2011 16:35, Nikola Skoric <nskoric@REDACTED> wrote:

> This is my first serious erlang project, and project structure changes
> as I grasp erlang patterns and best practices. I try really hard to
> conform to expected structures, and if you have any advice, I'll take
> it very seriously :-)
>
>
Not to worry. I won't pretend to be an expert, but I'll point out general
stuff if it's obvious and I'm sure many others will be willing to chime in.
Erlang has an excellent and supportive community.


> > why not use reltool.config if you're using reltool
>
> I started exploring reltool today and for now I have no luck with the
> tool, so I didn't commit my .config file to master yet. But you can
> see current state of my .config file from previous emails.
>
>
The config that rebar generates works perfectly well, so you could try
using that instead:

{sys, [
       {lib_dirs, []},
       {rel, "egon_server", "0.1",
        [kernel, stdlib, sasl]},
       {rel, "start_clean", "",
        [kernel, stdlib]},
       {boot_rel, "egon_server"},
       {profile, embedded},
       {excl_archive_filters, [".*"]}, %% Do not archive built libs
       {excl_sys_filters, ["^bin/.*",
                           "^erts.*/bin/(dialyzer|typer)"]},
       {app, hipe, [{incl_cond, exclude}]},
       {app, sasl, [{incl_cond, include}]}
      ]}.


> > why are there beams in your src dir that aren't part of the .app
> resource file?
>
> You mean "erl files", not "beam files", right? That would be es_tests
> and es_releasing, as far as I'm aware. Those are helper modules which
> are not intended for production.
>
>
I actually "beam files in your ebin" but never mind. :)

Non-production code should go into a 'test' directory rather than 'src' if
possible. If the 'es_releasing' module is part of the build process (rather
than the actual application) then there are a few options really. You can
have another sub-directory (such as 'build' or whatever) or you can convert
such modules to an escript and call them as part of your build process.

If you're using rebar, you can implement custom build behaviours (such as
custom commands, pre/post command hooks, etc) as plugins which may reside
anywhere and will be automatically compiled from source when required.


> > Try this:
> > t4@REDACTED:erlang-questions $ git clone
> > https://github.com/egon-sim/egon_server.git && cd egon_server
> > t4@REDACTED:egon_server $ mkdir rel
> > t4@REDACTED:egon_server $ vi rebar.config
>
> Right, rebar. Yes, I hear rebar is an excellent tool, but
> unfortunately, most of the time I code on a WinXP machine without
> admin rights and cut off from the Net. Last time I tried compiling it
> on this machine, it failed, and I just went with systools, since it
> was less trouble. It might be the right time to look into rebar again.
>
>
IIRC rebar will work (for the most part) in WinXP. If you get on to the
rebar mailing list and let people know what issues you had compiling it,
you'll get help very quickly.


> Thanks for help!
>
>
np. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111117/9359d3d5/attachment.htm>