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
. In that repository the
"lib" directory. It only contains the files: LICENSE package.json README.md
My guess is that since "lib" is an empty directory, it got lost when our
internal repository was created.
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?
Unfortunately, just changing the CMakeFiles.txt to
doesn't work. I get an error since the directory doesn't exist.
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!!
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.
Thanks for looking into this.
What do you think of the approach that I've taken? My rationale for
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
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
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).