ACE TAO Programming [003] 介绍

怎么编译ACE？

请参考 path.to.ace.root/ACE_wrappers/ACE-INSTALL.html 这个HTML文件，讲得很详细，至少我参考，在RHEL5上编译通过。

http://blog.csdn.net/JonsenElizee/archive/2009/09/04/4519896.aspx 中Installation节有介绍。

ACE Programmer's Guide, The: Practical Design Patterns for Network and Systems Programming
By StephenD.Huston , JamesCEJohnson , UmarSyyid
Publisher	: Addison Wesley
Pub Date	: November 14, 2003
ISBN	: 0-201-69971-0
Pages	: 544

这本书是很好的开始教材。

"This book is a must-have for every ACE programmer . For the beginner , it explains step-by-step how to start using ACE. For the more experienced programmer, it explains in detail the features used daily, and is a perfect reference manual. It would have saved me a lot of time if this book had been available some years ago"!
-Johnny Willemsen, Senior Software Engineer, Remedy IT, The Netherlands

The ACE Programmer's Guide is a practical, hands-on guide to ACE for C++ programmers building networked applications and next-generation middleware. The book first introduces ACE to beginners . It then explains how you can tap design patterns, frameworks, and ACE to produce effective, easily maintained software systems with less time and effort. The book features discussions of programming aids, interprocess communication (IPC) issues, process and thread management, shared memory, the ACE Service Configurator framework, timer management classes, the ACE Naming Service, and more.

How to Build Your Applications

The scheme used to build ACE can also be used to build your applications. The advantage to using the supplied scheme is that you take advantage of the built-in knowledge about how to compile and link both libraries and executable programs properly in your environment. One important aspect of that knowledge is having the correct compile and link options to properly include ACE and the necessary vendor-supplied libraries in each step of your build. Even if you don't use the ACE build scheme, you should read about how the compile and link options are set for your platform to be sure that you do compatible things in your application's build scheme.

This is a small example of how easy it is to use the GNU Make-based system. Microsoft Visual C++ users will not need this information and can safely skip to Section 2.5.1 .

If you have a program called hello_ace that has one source file named hello_ace.cpp , the Makefile to build it would be:

BIN   = hello_ace
BUILD = $(VBIN)
SRC = $(addsuffix .cpp,$(BIN))
LIBS = -lMyOtherLib
LDFLAGS = -L$(PROJ_ROOT)/lib
#---------------------------------------------------
#Include macros and targets
#---------------------------------------------------
include $(ACE_ROOT)/include/makeinclude/wrapper_macros.GNU
include $(ACE_ROOT)/include/makeinclude/macros.GNU
include $(ACE_ROOT)/include/makeinclude/rules.common.GNU
include $(ACE_ROOT)/include/makeinclude/rules.nonested.GNU
include $(ACE_ROOT)/include/makeinclude/rules.bin.GNU
include $(ACE_ROOT)/include/makeinclude/rules.local.GNU

That Makefile would take care of compiling the source code and linking it with ACE and would work on each ACE platform that uses the GNU Make-based scheme. The LIBS = -lMyOtherLib line specifies that, when linking the program, -lMyOtherLib will be added to the link command; the specified LDFLAGS value will as well. This allows you to include libraries from another part of your project or from a third-party product. The ACE make scheme will automatically add the options to include the ACE library when the program is linked. Building an executable program from multiple source files would be similar:

BIN = hello_ace
FILES = Piece2 Piece3
SRC= $(addsuffix .cpp,$(FILES))
OBJ= $(addsuffix .o,$(FILES))
BUILD   = $(VBIN)
#---------------------------------------------------------
# Include macros and targets
#---------------------------------------------------------
include$(ACE_ROOT)/include/makeinclude/wrapper_macros.GNU
include$(ACE_ROOT)/include/makeinclude/macros.GNU
include$(ACE_ROOT)/include/makeinclude/rules.common.GNU
include$(ACE_ROOT)/include/makeinclude/rules.nonested.GNU
include$(ACE_ROOT)/include/makeinclude/rules.bin.GNU
include$(ACE_ROOT)/include/makeinclude/rules.local.GNU

This Makefile would add Piece2.cpp and Piece3.cpp to the hello_ace program, first compiling the new files and then linking all the object files together to form the hello_ace program.

The following example shows how to build a shared library from a set of source files:

SHLIB   = libSLD.$(SOEXT)
FILES   = Source1 Source2 Source3
LSRC    = $(addsuffix .cpp,$(FILES))
LIBS   += $(ACELIB)
BUILD   = $(VSHLIB)
#-----------------------------------------------------------
#       Include macros and targets
#-----------------------------------------------------------
include $(ACE_ROOT)/include/makeinclude/wrapper_macros.GNU
include $(ACE_ROOT)/include/makeinclude/macros.GNU
include $(ACE_ROOT)/include/makeinclude/rules.common.GNU
include $(ACE_ROOT)/include/makeinclude/rules.nonested.GNU
include $(ACE_ROOT)/include/makeinclude/rules.lib.GNU
include $(ACE_ROOT)/include/makeinclude/rules.local.GNU

#----------------------------------------------------------
#       Local targets
#----------------------------------------------------------
ifeq ($(shared_libs),1)
ifneq ($(SHLIB),)
CPPFLAGS     += -DSLD_BUILD_DLL
endif
endif

This Makefile builds libSLD.so —the suffix will automatically be the correct one for shared libraries on the build platform—by compiling Source1.cpp , Source2.cpp , and Source3.cpp and then linking them by using the appropriate commands for the build platform.

The last section of the previous Makefile example conditionally adds a preprocessor macro named SLD_BUILD_DLL when building a shared library. This is related to the need to declare library functions as "exported" and is needed mostly on Windows. The next section discusses this further.

2.5.1 Import/Export Declarations and DLLs

Windows has specific rules for explicitly importing and exporting symbols in DLLs. Developers with a UNIX background may not have encountered these rules in the past, but they are important for managing symbol usage in DLLs on Windows. The rules follow.

• When building a DLL, each symbol that should be visible from outside the DLL must have the declaration __declspec (dllexport) to specify that the symbol or class members are to be exported from the DLL for use by other programs or DLLs.

• When declaring the use of a symbol that your code is importing from another DLL, your declaration of the symbol or class must include __declspec (dllimport) .

Thus, depending on whether a particular symbol or class is being imported from a DLL or being built into a DLL for export to other users, the declaration of the symbol must be different. When symbol declarations reside in header files, as is most often the case, a scheme is needed to declare the symbol correctly in either case.

ACE makes it easy to conform to these rules by supplying a script that generates the necessary import/export declarations and a set of guidelines for using them successfully. To ease porting, the following procedure can be used on all platforms that ACE runs on.

1. Select a concise mnemonic for each DLL to be built.

2. Run the $ACE_ROOT/bin/generate_export_file.pl Perl script, specifying the DLL's mnemonic on the command line. The script will generate a platform-independent header file and write it to the standard output. Redirect the output to a file named mnemonic _export.h .

3. Include the generated file in each DLL source file that declares a globally visible class or symbol.

4. To use in a class declaration, insert the keyword mnemonic _Export between the class keyword and the class name.

5. When compiling the source code for the DLL, define the macro mnemonic_BUILD_DLL (SLD_BUILD_DLL in the previous example).

   Following this procedure results in the following behavior on Windows.

   • Symbols decorated using the preceding guidelines will be declared using __declspec (dllexport) when built in their DLL.

   • When referenced from components outside the DLL, the symbols will be declared __declspec (dllimport) .

If you choose a separate mnemonic for each DLL and use them consistently, it will be straightforward to build and use DLLs across all OS platforms.

2.5.2 Important Notes for Microsoft Visual C++ Users

As mentioned, the GNU Make scheme is not used with Microsoft Visual C++. All needed settings are recorded in Visual C++'s project files. Because there's no common "include" file that a project can reuse settings from, each project must define the correct settings for each build configuration: debug versus release, DLL versus LIB, MFC versus non-MFC. Settings important for proper ACE usage follow. These descriptions are valid for Visual C++ version 6, and are all accessible via the Project>Settings... menu.

Table 2.3. ACE Library File Names for Visual C++

Configuration

File Name

DLL debug	aced
DLL release	ace
Static library debug	acesd
Static library release	aces
MFC DLL debug	acemfcd
MFC DLL release	acemfc

• C/C++ tab

  • Code Generation category: Choose a multithreaded version of the runtime library.

  • Preprocessor category: You should include $(ACE_ROOT) in the "Additional include directories" field. Some users choose to include $(ACE_ROOT) in the Tools>Options... menu on the Directories tab. This is acceptable if you always use one version of ACE for all projects. It is more flexible, however, to specify the ACE include path in each project.

• Link tab

  • Input category: Include the proper ACE library file in the "Object/library modules" field. Unlike the POSIX platforms, the name of the ACE library is different for various build configurations. Table 2.3 lists the ACE library file names. Select the desired name and append .lib to it to get the file name to add to the "Object/library modules" field. When building a debug configuration of your project, you should choose one of the debug ACE files as well—similarly, choose a release ACE file for a release build of your project—or you may get errors at link time.

  • Input category: Include the path to the ACE library link file in the "Additional library path" field. This will generally be $(ACE_ROOT)/ace . If you're linking with an ACE DLL, the export library file (.LIB ) is in $(ACE_ROOT)/ace , and the matching DLL your program will access at runtime is in $(ACE_ROOT)/bin ; it has the same base name but a .DLL suffix. Do not include $(ACE_ROOT)/bin in the "Additional library path" field. Instead, either include %ACE_ROOT%/bin in your PATH environment variable, or copy the needed DLL file to a location that is part of the PATH.