Sigh. No prizes for guessing what will happen in two years' time when node.js is no longer the shiny new hotness.
>Honestly, I don't understand the unnecessary snarkiness of some people on this site.
Reflexive negativity is a problem, pg is aware of it. Hiding comment karma score was one attempt at mitigating it, hopefully he's got some more ideas as well. Definitely one of those big problems, with the Internet in general, looking for a solution.
I don't really see any "reflexive negativity" in the original comment.
It's merely pointing out what seems to be a trend with this project and the build systems it uses. If there's any negativity involved, it's with how much time and effort (and donations...) the Cappuccino crew wastes with all of this repeated switching to the most-hyped software of the day.
If they hadn't switched people would be complaining that they use such an outdated system as jake.
If pragmatism was their main concern, then they would have been using make, shell scripts and the common UNIX commands from the very beginning. This would have given them support for Linux, Solaris, the *BSDs, Mac OS X and a number of other systems right away. Windows could've been supported with ease by using the various ports of those tools. Those tools are extremely capable and well-proven for creating reliable, cross-platform build scripts.
I'm not sure why people are recommending make. Apart from the fact that it makes perfect sense for a library written in JS to use a JS toolchain, tools like Rake and npm are far more portable than any of the Autotools toolchain ever was. OSX uses BSD make by default for god's sake, and installing autotools on windows is not nearly as easy as installing node and npm. After that, you've got hundreds (thousands?) of CommonJS libraries that you can leverage where you control the version, versus having files sprinkled with comments like "// curl version <7 didn't support the -p flag, needed for WinXP cygwin v.24" (not actual example, but I've worked on many C/C++ projects where this is the case).
There are benefits when the entire community standardizes on something. I know I will frequently pass looking at a Python module that won't easily fit into my build system, which, conveniently, is the build system mostPython scripts use.
The fact that Cappuccino pre-dated the de facto standard should not be held against them.
Anybody looking into a package management solution should just use nix and be done with it.
Works on Linux, Mac, Windows, BSD, probably others.
Language-agnostic (and build-system agnostic) so if your project ends up depending on bindings to a specific version of libjpeg or some other C library, you won't be stuck. Likewise if you have perl/ruby glue scripts in your project (which is bound to happen), their dependencies can be properly modeled too.