[erlang-questions] WTF?

[Tim Watson]

> The issue was -caused- by the rebar generation pass; getting back
> -out- was hindered by the backgrounded process.
>

Ah ok, I didn't realise that at first.

> As it stands, something is borked because that directory is now
> "corrupted" somehow.  I nuke the directory and do a full rebuild and
> the .ez file does not have the .beam files...only the .app file.
> I can now compile and run perfectly in any other directory....just not
> that one.  And I've rebooted and nuked the filesystem tree.
>
> It's very strange.  It's like something is pattern-matching on the
> directory structure/name and causing problems.
>

Does seem very weird. Have you submitted this to the rebar mailing
list for analysis? I haven't seen any posts. Also submitting a github
issue with the output from `rebar generate -v` would be useful if
that's a possibility.

> FWIW, I really ke erlang's syntax ... and my comments above were
> directed more towards build/release than erlang proper.  Rebar does an
> admirable job of pulling things together but even though Erlang's been
> around a while it's not had the level of tools-maturity that other
> platforms have had.  (Clarification there: They're mature if you're
> in-the-know and have learned the arcane but they're not terribly
> user-friendly which is a major obstacle to widespread acceptance.)

Yes I agree that the tools support is a little lacking. Thankfully
Erlang is simple enough that this isn't often a problem, but when you
do run into issues with the tools it can be a real pain to isolate and
fix them.

>
> Perhaps, as mentioned above, the correct course for me is to use make
> for more than just front-ending rebar.  However, while fluent in make,
> that requires a deeper dive into the build/release process which then
> pushes back on project release timelines.  :)
>

Yeah indeed - make is good and all but few people would dream of
building a java project without ant or maven (or even gradle and what
have you) so having a tool that "does the right thing" most of the
time and can be extended when required is a very good thing IMO. Even
C/C++ projects can benefit from more user friendly tools these days.

I seriously think engaging with the rebar mailing list and talking to
the developers would be worthwhile - they're very helpful and there's
a lot of knowledge and experience on the mailing list especially
around the release generation and app-upgrade features.