Wed Jul 6 20:01:22 CEST 2011
On Wed, Jul 6, 2011 at 3:58 AM, Tim Watson <watson.timothy@REDACTED> wrote:
> So that culprit was not rebar of anything to do with rebar?
> So rebar is an effort to make a good build/packaging system for
> erlang. The problems you encountered don't seem to be directly
> related, as the aforementioned culprit was some other background
The issue was -caused- by the rebar generation pass; getting back
-out- was hindered by the backgrounded process.
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.
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.)
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. :)
More information about the erlang-questions