Wed Jul 6 07:38:51 CEST 2011
Why re-invent make and make it worse? No, really. Typically, you'll want to
use code generation, and multiple languages, and perhaps custom build steps,
unit tests, functional tests, ... All of which works great in Make with some
smart wildcards and implicit rules. No offense to the rebar lovers, but you
can pry GNU make out of my cold, dead hands; not before :-)
Our Erlang build uses a Python-based unit test driver, builds a few C-based
tools, and generates Erlang, Python and PHP marshalling glue for our network
protocol. Oh, and also acceptance tests our bash-based deployment scripts.
Rebar didn't deal with that when I tried.
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world. Nevertheless,
whether we get there willingly or not, we shall soon have lower consumption
rates, because our present rates are unsustainable.
On Tue, Jul 5, 2011 at 6:04 PM, Kenny Stone <kennethstone@REDACTED> wrote:
> I love erlang's syntax <3
> rebar can be a big magical and scary...
> On Tue, Jul 5, 2011 at 7:52 PM, Mike Oxford <moxford@REDACTED> wrote:
>> erl running inside of a backgrounded emacs in the original directory
>> seems to have been the culprit.
>> Killed it off, nuked the directory, used the merged backup with the
>> rebuilt-nodes and things are good again.
>> If two things are going to kill Erlang's uptake it's not going to be
>> the syntax, the performance, the functional-way-of-thinking... it'll
>> be the terrible error messages and the arcane build/packaging, both of
>> which make Erlang feel like a house of cards you can't even look at
>> wrong and, thus, give no confidence in actually running it in
>> production. (Not to mention just plain annoying devs to the point
>> they walk away from it, which is what kills more languages over time
>> than anything else.)
>> Party on...
>> On Tue, Jul 5, 2011 at 5:09 PM, Mike Oxford <moxford@REDACTED> wrote:
>> > Application tree was working...has been for weeks.
>> > Ran rebar and it crashed, shit all over my nodes (again.) No problem,
>> > been there done that, fix it up...
>> > Now when I run it (after rebar's generate) it gives me the "undef
>> > start/2" error.
>> > Spend hours trying to figure out everything from how my lib_dirs got
>> > changed, env, everything, full cleans, everything.
>> > Pull a backup ... it works.
>> > Hand merge all new changes... works, runs fine.
>> > Nuke the directory and copy the backup into the directory....undef
>> > Copy the entire tree to another directory ... runs fine.
>> > What/where/WTF has been corrupted that running it from a specific
>> > directory would cause issues?
>> > /opt/name/proj <-- undef start/2, used to work
>> > /opt/name/wtf/proj <-- works
>> > My lib_dirs have not changed, binary cp -r between the two directories
>> > so they're identical.
>> > Rebar may have caused it, but now that it's in this completely f'd up
>> > state I need to figure out how to get it OUT of this state, since
>> > rebar's just a packaging system in front of erlexec.
>> > So ... two identical directory structures, one works and one does not.
>> > Again, it's been working for weeks .. this is not a fundamental issue
>> > but more "state."
>> > I have -not- rebooted. I want to understand this fully before I push
>> > in into production.
>> > Anyone know of a good place to start digging?
>> > TIA.
>> > -mox
>> erlang-questions mailing list
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions