Phil,
The only shared-object in that list that is a proper "library" is
libqpid-proton.so. The others are extension modules for their various
scripting languages. I'm not 100% sure, but I believe that the naming
conventions are dictated by the scripting language's extension mechanisms.
-Ted
On 01/04/2013 10:47 AM, Phil Harvey wrote:
I've been working on the Java binding of proton-c and have a couple of
questions about how we're naming our various libraries.
On Linux, running "make all" produces the following:
bindings/ruby/cproton.so
bindings/python/_cproton.so
bindings/perl/libcproton_perl.so
bindings/libproton-swig.so (on JNI branch only)
libqpid-proton.so
=== 1. Naming conventions ====
All things being equal, we should adopt a consistent approach regarding:
- whether to put a "lib" prefix on the file name (my preference is to
always do this)
- whether the language name should appear in the bindings libraries.
I'm guessing that all things are *not* equal, and that we have deliberately
named the bindings differently for some reason. Can anyone enlighten me?
==== 2. The "lib" prefix on old cmake versions ====
Regarding the "lib" prefix, I am using an old version of cmake (v2.6) which
does not add the prefix by default. I can add
'set_target_properties(proton-xxx PROPERTIES PREFIX "lib")' as a
workaround. This still works ok on newer cmake versions.
Unfortunately I think this will force Windows dll's to have the "lib"
prefix, which is undesireable.
Can anyone advise on the best approach? I'm not a cmake expert.
Thanks
Phil
