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
