activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Albert Strasheim (JIRA)" <j...@apache.org>
Subject [jira] Updated: (AMQCPP-115) Change build to create dynamic libraries
Date Fri, 18 May 2007 16:48:34 GMT

     [ 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.


Mime
View raw message