On Tue, 2013-11-19 at 19:56 +0000, Fraser Adams wrote: > Hey all, > For the last couple of weekends I've been working on a Proof of Concept > JavaScript implementation of Proton. > > The approach that I've taken is (I think) quite interesting/unusual but > it's an approach that offers a high level of synergy with > implementations for other languages that are essentially bindings to > proton-c. > > The "magic elixir" in this is the downright amazing emscripten > https://github.com/kripken/emscripten/wiki which (believe it or not) is > essentially a cross-compiler that can compile C/C++ to JavaScript. > Moreover the JavaScript that it compiles to is a particular subset > called asm.js http://asmjs.org/ which can be extremely aggressively > optimised and is subject to a lot of research by Mozilla in particular > (the main emscripten maintainer is actually a Mozilla researcher, though > I believe emscripten is something of a side project). > > It's well worth visiting the emscripten page with a modern browser, the > Epic Citadel demo is awesome :-) > > So in a nutshell what I've done is to compile proton-c into JavaScript > > So I'm underselling it a bit :-) I had to do a fair bit of work to make > it that simple, in particular I had to add/fix a number of emscripten's > library functions (Proton used a few things that weren't implemented) > but the cool thing is that those are now in emscripten for everyone's > benefit. > > A really nice thing is that I've not actually had to modify any of the > engine/messenger code at all - one I started to figure out what I was > doing wrong that is :-) all I've really needed to to was to modify > send.c/recv.c so that they behave in a non-blocking manner (you may have > seen my mail at the weekend before I finally figured it out :-)) > > I've got CMake able to cross-compile in a repeatable fashion so the only > change to any existing Proton stuff that is required is an addition to > the top-level CMakeLists.txt that detects the presence of emscripten and > its dependencies and if present fires off > "add_subdirectory(bindings/javascript)" e.g. > > > # Build the JavaScript language binding. > # This is somewhat different to the other language bindings in that it > does not use swig. It uses a C/C++ to > # JavaScript cross-compiler called emscripten > (https://github.com/kripken/emscripten). Emscripten takes C/C++ > # and "compiles" it into a highly optimisable subset of JavaScript > called asm.js (http://asmjs.org/) that can > # be aggressively optimised and run at near-native speed (usually > between 1.5 to 10 times slower than native C/C++). > option("BUILD_JAVASCRIPT" "Build JavaScript language binding" ON) > if (BUILD_JAVASCRIPT) > # First check that Node.js is installed as that is needed by emscripten. > find_program(NODE node) > if (NOT NODE) > message(STATUS "Node.js (http://nodejs.org) is not installed: can't > build JavaScript binding") > else (NOT NODE) > # Check that the emscripten C/C++ to JavaScript cross-compiler is > installed. > find_program(EMCC emcc) > if (NOT EMCC) > message(STATUS "Emscripten > (https://github.com/kripken/emscripten) is not installed: can't build > JavaScript binding") > else (NOT EMCC) > add_subdirectory(bindings/javascript) > endif (NOT EMCC) > endif (NOT NODE) > endif (BUILD_JAVASCRIPT) >
BTW this whole approach to checking dependencies is not something you should copy from the existing proton/qpid code it is really not the idiomatic cmake way to do this - in our defense up till now we've really being doing cmake just to make it work, and our cmake code base is (IMO) just starting to get large enough to be hard to follow and so we need to take more care. The idiomatic approach involves writing smaller FindXXX.cmake files which return a fixed set of variables and using find_package(XXX...) in the main cmake file. > > So the main purpose of this mail is to give a heads up of it and to ask > if it'd be OK to start commiting it and give others some visibility of it. This seems quite cool, I'd suggest you use a branch to allow others visibility into what you are doing, but it doesn't sound quite ready for trunk checkin just yet. Andrew --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
