#33 patched
John-David Dalton

Convert from Ruby to another build system.

Reported by John-David Dalton | July 4th, 2009 @ 09:40 AM | in Iteration 3

JavaScript MVC uses Rhino for a 100% pure JavaScript build system.
I am very interested in this.

Comments and changes to this ticket

  • Kit Goncharov

    Kit Goncharov August 2nd, 2009 @ 12:18 PM

    • Assigned user changed from “John-David Dalton” to “Kit Goncharov”
    • State changed from “new” to “open”
    • Tag set to build
    • Title changed from “Convert from Rails to another build system.” to “Convert from Ruby to another build system.”

    I still prefer using Ruby as a build system -- I do have several peeves with Rhino. For one, a Rhino build script wouldn't really cross-platform. JavaScriptMVC has two scripts inside it: a shell script for OS X/*NIX and a batch file for Windows. JSMVC's code also looks like it's geared more toward building an actual app (something like what Rails would do), as opposed to just a single composite file. Also, if we want to make Fuse modular (so the user can do something like build include=Core,NWMatcher,Enumerable from the command line), dependency management would be a must. I haven't seen many libraries for Rhino (much less ones that are built for the aforementioned tasks), so I think we'd need to write our own library for that.

    I did, though, have a pretty pleasant experience writing Miniatures' build system -- it's a very simplified example of how Ruby can be used to build a customized JavaScript library while including all necessary dependencies. Basically, I have a small YAML file where I define the modules and their dependencies. Then, in my Rakefile, I use Ruby's built-in YAML parser to load the YAML file into a Ruby hash. If the user specifies an include argument (i.e., rake build include=DOMReady,NWMatcher), the build task loads the modules and their dependencies, and stores their paths in an array. If the user doesn't specify which modules to include, all of the modules are added. Then, I add the header file to the beginning of the array, and pass that array as an argument to Sprockets, which builds the final distribution file.

    I hope this doesn't appear trollish...I definitely think, though, that Ruby would be the way to go for building a JS library. MooTools, Prototype, and SproutCore already do this, so the build process would be fairly familiar to users of those libraries. Also, Ruby does have quite a few libraries for building JS frameworks already (like Ruby-YUI Compressor, Sprockets, and PackR), so we'd be saving ourselves quite a lot of time by not having to write our own build library for Rhino.

    Again, all this is my opinion and stems from personal experience more than anything, so I guess I'm not being very objective. I'll go ahead and read up more on the ins and outs of the Rhino environment, though, and how it can be used for a build system.

  • Kit Goncharov

    Kit Goncharov August 2nd, 2009 @ 12:30 PM

    My Rakefile and YAML dependency list, if you're interested. :D

  • John-David Dalton

    John-David Dalton August 2nd, 2009 @ 12:44 PM

    Wow. Thanks for all the info :). Could some of this be done in Python or via Ant ?

  • Kit Goncharov

    Kit Goncharov August 2nd, 2009 @ 02:52 PM

    I don't have any experience with Python, but I guess it could be done. I do remember reading an article about Ant though -- it's really similar to Rakefiles, except you really don't have access to the underlying language. I'll read up more on both of them and see what I can find out.

  • Diego Perini

    Diego Perini August 3rd, 2009 @ 01:18 PM

    • Tag changed from build to build, nix

    good additions, seems you are already advanced at covering Ruby and stuff.

    I have built myself a very simple *NIX shell build for FuseJS and would like to know if it this is something to consider adding to the list of build methods for others.

    I am currently using this on a Mac and the process make use of "jsl.c" by Mathias Miller to do a "lint" pass (with logs) and "jsmin.c" by Douglas Crockford to minify it.

    The requirements are a C compiler for the "lint" and "minifier" and a *NIX shell, I already have pre-built binaries for (Mac/Linux).

    It still misses the cross-compiling part of those two C snippets but that will be easy enough to add.

    Let me know.

  • Kit Goncharov

    Kit Goncharov August 3rd, 2009 @ 01:45 PM

    Sure, that definitely sounds interesting! The only thing I'm on the fence about is the requirement of a C compiler -- I think most Linux distros come with the option to install the gcc package, but neither Windows or OS X does. I don't know about the options available for Windows (I'd guess emulation via Cygwin), but OS X requires that you install 2GB worth of dev tools just to use the compiler. If you have pre-built binaries, though, that's great.

    I'll be gone for most of this week (I'm leaving in a couple of hours, and will get back Saturday), but I'll definitely be interested in seeing your *NIX shell!

  • Kit Goncharov

    Kit Goncharov August 3rd, 2009 @ 01:50 PM

    On a side note, I just realized that the Rakefile I uploaded previously was totally incomplete. Here's an updated version (I haven't changed the comments at the top, but the code itself should be a lot easier to understand):

  • Diego Perini

    Diego Perini August 4th, 2009 @ 01:30 PM

    it is obvious we are aiming at more build system not just replace one with another.

    I got your point thanks, forcing the user to have a C compiler is not a good idea.

    I already have binaries for all the platforms so I will soon post the archive containing the relevant files and instructions. I am just trying it on Linux/Mac to ensure at least these two OS works.

    I will need to go back to ".bat" files to achieve the same on Windows but I feel a bit lazy so it is fine if somebody else feel more comfortable with ".bat" syntax and would like to take over that part.

  • Diego Perini

    Diego Perini August 7th, 2009 @ 05:47 AM

    Here is my mini shell build tool.

    In the "bin" directory there are pre-compiled binaries for Mac, Linux and Windows.

    The "src/fuse-c.js" file is a temporary copy of "src/fuse.js" to keep my script easy.

    To install in the local repo do:

    • copy "bin" directory to
    • copy "src/fuse-c.js" to /src
    • copy Makefile to

    the useful scripts in the "bin" directory are:

    fuselint.sh (to execute the lint pass, output in <gitroot>lint.log)
    fusedist.sh (to execute the build pass, source + minified in <gitroot>/dist)

    to use with a standard (&simple) *NIX "make" I included a Makefile too:

    • make clean
    • make lint
    • make build

    to "make" a complete build just type (or always just do that):

    • make

    Things missing (not in order):

    • create a detailed log file for the build with stats for each module
    • improve checking existence of file and throw warnings in the log
    • accept more options like "target" names of single javascript files for lint
    • extract list and order of files in a separate archive to easy maintenance
    • the above could also help in setting up a Web interface for on line ad hoc builds
    • more...

    Let me know if you see something missing or wrong.

  • Kit Goncharov

    Kit Goncharov August 7th, 2009 @ 08:07 PM

    Sorry, not sure what you mean by "it is obvious we are aiming at more build system not just replace one with another." I'm guessing you mean that we should have multiple build systems (so users can pick to build Fuse using Ruby, Rhino, shell, etc.), but please correct me if I'm wrong.

    Can you recommend another C compiler for OS X besides Xcode? The last time I tried installing it, it completely trashed my system and I had to do a destructive reinstall.

    Also, I apologize if my post isn't clear. I just got back from high altitude, so my head is still a little fuzzy. :)

  • Diego Perini

    Diego Perini August 11th, 2009 @ 09:59 AM

    Correct Kit,
    sorry for my bad english, that's what I meant "have multiple build systems" to choose from.

    I am not so well informed about other C compilers for Mac. I use "gcc" which I think comes with Xcode, I haven't had problems with it, but as I said there are already precompiled binaries in my shell build for all systems so no need for a compiler.

    Will be back in my office next Monday. Would like to exchange some ideas on how to use a common file to keep module names and dependencies so any build system can reference that same info.

  • Kit Goncharov

    Kit Goncharov August 11th, 2009 @ 11:00 AM

    No problem! I'll go ahead and further test out your shell and start
    rewriting the build system.

  • Diego Perini

    Diego Perini August 12th, 2009 @ 12:53 PM

    What about having dependencies listed in order inside the head of the source files themselves as comment lines ?

    Something like:

    /* @deps: file1, file2, file3 */

    this maybe will make the building process easier and will avoid more external files.

    Having the dependencies inside build scripts (in different formats) seems to me it requires more maintenance work. Every build system could then extract their hashes in a standard way and the dependencies information will be strictly bound with the related archive.

  • Diego Perini

    Diego Perini August 13th, 2009 @ 01:25 PM

    For the above shell build archive, you will have to change the <git_local_path> in both:


    To make it work in your environment change the line near the top saying:


    to your local git repository path.

    Will try to make that external to the scripts, maybe in the Makefile itself where it pertains.

    Sorry for the late infos...

  • Joe Gornick

    Joe Gornick October 7th, 2009 @ 01:38 AM

    • Assigned user changed from “Kit Goncharov” to “Mark Caudill”
  • Joe Gornick

    Joe Gornick September 19th, 2010 @ 05:47 PM

    • Milestone cleared.
    • Milestone order changed from “0” to “0”
  • Joe Gornick

    Joe Gornick September 29th, 2010 @ 09:45 AM

    • Milestone cleared.
    • Assigned user changed from “Mark Caudill” to “Joe Gornick”
    • Milestone order changed from “2” to “0”
  • Joe Gornick

    Joe Gornick February 21st, 2011 @ 05:09 PM

    • State changed from “open” to “new”
    • Assigned user changed from “Joe Gornick” to “Kit Goncharov”
  • Kit Goncharov

    Kit Goncharov February 28th, 2011 @ 10:20 PM

    • State changed from “new” to “open”
  • Kit Goncharov

    Kit Goncharov March 5th, 2011 @ 09:56 PM

    • State changed from “open” to “patched”
    • Milestone set to Iteration 1
    • Assigned user changed from “Kit Goncharov” to “John-David Dalton”
    • Milestone order changed from “5” to “0”
  • Joe Gornick

    Joe Gornick March 9th, 2011 @ 11:16 AM

    • Milestone changed from Iteration 1 to Iteration 2
    • Milestone order changed from “10” to “0”
  • Joe Gornick

    Joe Gornick March 22nd, 2011 @ 09:41 PM

    • Milestone changed from Iteration 2 to Iteration 3
    • Milestone order changed from “1” to “0”

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

JavaScript frameworks share similar features and functionality such as DOM manipulation, event registration, and CSS selector engines. FuseJS attempts to incorporate the strengths of these frameworks into one stable, efficient, and optimized core JavaScript framework.