Hi Ernie

. In that repository the
fadams-javascript-binding/proton-c/bindings/javascript/qpid-proton does NOT contain a 
"lib" directory. It only contains the files: LICENSE  package.json  README.md
Yeah that's likely to be the root of your problem, without that lib directory being in place the copy command will indeed copy proton.js to a file called lib



My guess is that since "lib" is an empty directory, it got lost when our 
internal repository was created.
:-)

Unfortunately, just changing the CMakeFiles.txt to
         ${PROJECT_SOURCE_DIR}/node_modules/qpid-proton/lib/
doesn't work. I get an error since the directory doesn't exist.
Shame it doesn't work, though I guess not surprising. I'm torn between having the trailing slash or not, though you say that with it you get an error. Perhaps getting an error is preferable? In your case you had a silent issue originally, would an error have helped you track things down more quickly?


When I create the "lib" dir before the build, everything works as expected.
The real solution is to create the empty "lib" dir in the Red Hat repository. 
I'll look into doing that.
When I pull the source from the public svn link, everything builds just fine.
I'm glad that the public svn link works, yay!!


Thanks for looking into this.
-Ernie Allen

No probs, it's been my personal little baby for a while now, so it's a good thing that others are starting to take a peek. I think that quality wise it's pretty decent and pretty well commented and I think that the functional behaviour is largely all in place, but I haven't really looked at optimisation/profiling yet.

What do you think of the approach that I've taken? My rationale for compiling proton-c to JavaScript and using a thin (ish) binding layer rather than doing a ground-up "native" JavaScript rewrite was primarily about support. I figured that there was a lot of effort being put into maintaining proton-c and that was what might be considered the "canonical" or reference implementation, so tracking improvements would end up being a pain with a separate code-base, whereas the binding to a compiled library just needs to cover the public API and ultimately I should pick up improvements to the core code "transparently". If you look at what I've done you'll hopefully see a startling similarity with the SWIG bindings particularly the Python one. I spent some effort contributing to emscripten too, putting things in place so that proton-c compiles cleanly (if you look in fadams-javascript-binding/bld/proton-c/bindings/javascript/examples you will see recv-async.js and send-async.js, which are actually the results of directly compiling recv-async.c and send-async.c. Those were the first things I got working before I started on the binding stuff - I figured that JavaScript programmers probably wouldn't enjoy using a C API ;->)

I did a bit of work on the qpid-config port yesterday and it now does everything the python one does (well except the xml binding support at the moment as that loads a file). I'm currently trying to get it to work with the Java Broker (see my Java Broker AMQP 1.0 support - is it by default? post to the users list).

Cheers,
Frase




Reply via email to