[
https://issues.apache.org/activemq/browse/AMQCPP-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Albert Strasheim updated AMQCPP-115:
------------------------------------
Attachment: amqcppdllv1.diff
Here's a first cut of the patch so that we can discuss how we want to do this.
So far I've only looked at building a DLL on Windows. Once this infrastructure
is in place, I'll work on the autotools build.
I've added a src/main/cms/Config.h which contains the following:
#ifdef CMS_DLL
#ifdef CMS_EXPORTS
#define CMS_API __declspec(dllexport)
#else
#define CMS_API __declspec(dllimport)
#endif
#else
#define CMS_API
#endif
When building the DLL itself, you define CMS_DLL and CMS_EXPORTS. When linking
against the DLL, you define CMS_DLL. When building the code statically (or when
linking against the static library), you don't define anything extra. The *_DLL
and *_EXPORTS idea comes from stuff I've seen in wxWidgets and from what Visual
Studio's "make a DLL" wizard puts in the project it generates.
I've put the AMQCPP_DLL and AMQCPP_EXPORTS defines in activemq/util/Config.h.
Next up, I added two new configurations to the Visual Studio project files,
namely DebugDLL and ReleaseDLL. Keeping everything in a single project file is
handy, because this way you can build all the binaries you could need using a
batch build. Because of our spiffy settings for the output and intermediate
directories, the various builds don't step on each other, and everything you
need to run the example (even when linked against the DLL) ends up in one place.
Next minor change: the static library builds were changed to produce
libactivemq-cpp.lib and libactivemq-cppd.lib, for Release and Debug,
respectively. The ReleaseDLL and DebugDLL builds produce activemq-cpp.dll,
activemq-cpp.lib and activemq-cppd.dll and activemq-cppd.lib, respectively. The
.libs are the link libraries you need to link against the DLL and differ from
the static libraries. These naming conventions follow what the Boost project
does for their static libraries and DLLs (they also build variants for all the
various runtime options, but we can leave that for another day).
The only thing left to decide is which symbols we're going to export. I was
able to get the AMQCPP example program to link by exporting everything in CMS
(makes sense, since it's the public API) and AMQCPP's Thread and
ActiveMQConnectionFactory classes (makes sense again... one day Thread will be
pulled in from the Decaf lib, and ActiveMQConnectionFactory is the only class
the user needs to know about).
We have to decide if we're going to export some or all of the other AMQCPP
classes from the DLL. My first instinct would be not to export anything else,
except, temporarily, the classes that are going into Decaf. The thinking here
is that the user shouldn't know or care what classes the AMQCPP library uses to
implement the CMS API. The user literally only needs to be able to make a
ActiveMQConnectionFactory.
On the other hand, I've had to use a few internal AMQCPP classes to work around
some Stomp-specific issues (Stomp's "one selector per connection" limitation).
In this case it was handy to be able to get at a few of the internal AMQCPP
classes. I'll investigate this code again and see what extra exports it would
need to work.
Just remembered one other class that probably needs to be exported:
activemq::util::Properties. By the way, the CMS API refers to this class
directly. That is probably something that should be fixed for a future CMS API
release.
If we go for the "export only what the user needs" route, we won't be able to
link the unit and integration tests against the AMQCPP DLLs. This is probably
fine. Building of the tests can simply be disabled in the DebugDLL and
ReleaseDLL configurations (as they should be if VS stores that info in a place
where my patch would pick it up).
By the way, the current AMQCPP Release DLL weighs in at about 1 MB. Nice and
compact.
> Change build to create dynamic libraries
> ----------------------------------------
>
> Key: AMQCPP-115
> URL: https://issues.apache.org/activemq/browse/AMQCPP-115
> Project: ActiveMQ C++ Client
> Issue Type: Task
> Environment: *nix, win32
> Reporter: Nathan Mittler
> Assigned To: Nathan Mittler
> Priority: Minor
> Fix For: 2.1
>
> Attachments: amqcppdllv1.diff
>
>
> Based on a flurry of user requests, we need to add support for generating
> dynamic libraries to our automake scripts and the msvc project.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
