|  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
 | | 
 
 | |  |  |  |  |  |  Building Xerces-C++ on OS/2 using Visual Age C++ |  |  |  |  |  | 
 |  |  | OS/2 is a favourite IBM PC platforms. The only
          option in this platform is to use
          Visual Age C++ compiler.
          Here are the steps you need to build Xerces-C++ using
          Visual Age C++ on OS/2. | |  |  |  |  |  |  Building Xerces-C++ library |  |  |  |  |  | 
 |  |  | Requirements: 
                    VisualAge C++ Version 4.0 with Fixpak 1:
                    Download the
                    Fixpak
                    from the IBM VisualAge C++ Corrective Services web page.
 There are two ways to build Xerces-C++. The "From Existing" method only
                  requires VAC++. The "From Scratch" method requires both Object Rexx and VAC++
                  installed. The "From Existing" Method 
            In the xerces-c-src1_5_2\Projects\OS2\VACPP40directory,
            find and edit the VAC++ configuration fileproject_options.icc.Change the directory on the first line 'BASE_DIR = "..."'to match the base directory of the Xerces-C++ sources on your system.
            Note that the directory path must use double backslashes"\\"!Save project_options.iccStart the Command Line in the VAC++ folder.Navigate to the xerces-c-src1_5_2\Projects\OS2\VACPP40directory.Run build.cmd. This does a migration build.When build.cmdfinishes, review the filecompiler.errors.
            This file should contain only informational messages, almost all complaining
            about constant values in comparisons.You should now have a xerces-c.dllandxerces-c.lib.
            The library file is an import library for the DLL. The "From Scratch" Method 
            If you are not currently running Object Rexx,
            run theSWITCHRXcommand from a command line,
            answer"yes"to switching toObject Rexx, and follow the
            instructions to reboot. You can switch back to"Classic Rexx"by runningSWITCHRXagain. But you probably won't need to switch back sinceObject Rexxruns almost 100% of Classic Rexx programs.In the xerces-c-src1_5_2\Projects\OS2\VACPP40directory,
            rungenICC.cmd. This builds the VAC++ configuration files for
            the sources you have on your system.Check the generated ICCfiles to ensure that they didn't pick up some
            non-OS/2 platform stuff. This happens when new platform-specific directories
            are added to Xerces. If they did pick up new non-OS/2 stuff, either edit it out
            of theICCfile or add them to the "ignore" array ingenICC.cmdand
            re-rungenICC.Start the Command Line in the VAC++ folder.Navigate to the xerces-c-src1_5_2\Projects\OS2\VACPP40directory.Run build.cmdThis does a migration build.When build.cmdfinishes, review the filecompiler.errors.
            This file should contain only informational messages, almost all complaining about constant
            values in comparisons.You should now have a xerces-c.dllandxerces-c.lib.
            The library file is an import library for the DLL.) Packaging the Binaries There is an Object Rexxprogram that will package the binaries and headers.
          (See step 1 of the "From scratch" method on how to switch toObject Rexx.) ThepackageBinaries.cmdfile is in thexerces-c-src1_5_2\Projects\OS2\VACPP40directory. RunpackageBinaries, giving the source and target directories
          like this: |  |  |  |  |  | packageBinaries -s x:\xerces-c-src1_5_2 -o x:\temp\xerces-c1_5_2-os2 |  |  |  |  |  | 
(Match the source directory to your system; the target directory can be
          anything you want.) |  | If you don't want to use the Object Rexxprogram, you'll need to
          manually  copy the "*.hpp" and "*.c" files to an include directory.
          (Be sure to maintain the same directory structure that you find underxerces-c-src1_5_2.) | 
 | 
 
 | 
 
 | |  |  |  |  |  |  Building Xerces-C++ on AS/400 |  |  |  |  |  | 
 |  |  | The following addresses the requirements and build of
           Xerces-C++ natively on the AS/400.
             | |  |  |  |  |  |  Building Xerces-C++ library |  |  |  |  |  | 
 |  |  | Requirements: 
                    QSHELLinterpreter installed (install base option 30, operating system)QShell Utilities,  PRPQ  5799-XEHILE C++ for AS/400,  PRPQ 5799-GDWGNU facilities  (the gnu facilities are currently available by request
                    only.  Send e-mail to rchgo400@us.ibm.com) Recommendations: 
                There are a couple of options when building the Xerces-C++ parser on AS/400.
                For messaging support, you can use the in memory message option or the
                message file support. For code page translation, you can use the AS/400
                native Iconv400support or ICU. If you choose ICU, follow the instructions
                to build the ICU service program with the ICU download. Those instructions
                are not included here.Currently we recommend that you take the options of MsgFileandIconv400(see below) Setup Instructions: 
                Make sure that you have the requirements installed on your AS/400.
                We highly recommend that you read the writeup that accompanies the gnu
                facilities download.  There are install instructions as well as
                information about how modules, programs and service programs can be
                created in Unix-like fashion using gnu utilities.  Note that symbolic
                links are use in the file system to point to actual AS/400 *module,*pgmand*srvpgmobjects in libraries.Download the tar file  (unix version) to the AS/400
                (using a mapped drive), and decompress and untarthe source.
                We have had difficulty with the tar command on AS/400. This is under
                investigation.  If you have trouble, we recommend the following work
                around: |  |  |  |  |  | qsh:
gunzip -d <tar file.gz>
pax -r -f <uncompressed tar file> |  |  |  |  |  | 
                Create AS400 target library. This library will be the target
                for the resulting  modules and  Xerces-C++ service program. You will
                specify this library on the OUTPUTDIRenvironment variable
                in step 4Set up the following environment variables in your build process
                (use ADDENVVARorWRKENVVAR CLcommands): |  |  |  |  |  | XERCESCROOT - <the full path to your Xerces-C++ sources>
PLATFORM  - 'OS400'
MAKE   - '/usr/bin/gmake'
OUTPUTDIR  - <identifies target as400 library for *module, *pgm and *srvpgm objects>
ICUROOT - (optional if using ICU)  <the path of your ICU includes> |  |  |  |  |  | 
                Add QCXXN, to your build process library list.
                This results in the resolution ofCRTCPPMODused by theicccompiler.The runConfigure instruction below uses 'egrep'.
                This is not on the AS/400 but you can create it by doing the following:edtf '/usr/bin/egrep'with the following source: |  |  |  |  |  | #!/usr/bin/sh
/usr/bin/grep -e "$@" |  |  |  |  |  | 
You may want to put the environment variables and library list
         setup instructions in a CLprogram so you will not forget these steps
         during your build. Configure To configure the make files for an AS/400 build do the following: |  |  |  |  |  | qsh
cd <full path to Xerces-C++>/src
runConfigure -p os400 -x icc -c icc -m MsgFile -t Iconv400 |  |  |  |  |  | 
Troubleshooting: |  |  |  |  |  | error: configure: error: installation or configuration problem:
C compiler cannot create executables. |  |  |  |  |  | 
If during runConfigureyou see the above error message, it
         can mean one of two things. EitherQCXXNis not on your library
         list  OR therunConfigurecannot create the temporary
         modules (CONFTest1, etc) it uses to test out the compiler
         options. The second reason happens because the test modules already exist
         from a previous run ofrunConfigure. To correct the problem,
         do the following: |  |  |  |  |  | DLTMOD <your OUTPUTDIR library>/CONFT* and
DLTPGM your <OUTPUTDIR library>/CONFT* |  |  |  |  |  | 
Build The above gmake will result in a service program being created
         in your specified library and a symbolic link to that service program
         placed in <path to Xerces-C++/lib>. You can either bind your
         XML application programs directly to the parser's service program
         via the BNDSRVPGMoption on theCRTPGMorCRTSRVPGMcommand  or you can specify a binding directory
         on youricccommand. To specify an archive file to bind to,
         use the-L, -lbinding options on icc.  An archive file
         on AS/400 is a binding directory. To create an archive file, useqarcommand.  (see the gnu facilities write up). 
         After building the Xerces-C++ service program, create a binding directory
         by doing the following (note, this binding directory is used when building
         the samples): |  |  |  |  |  | qsh
cd <full path to Xerces-C++>/lib>
qar -cuv libxercesc1_1.a *.o
command = CRTBNDDIR BNDDIR(yourlib/libxercesc) TEXT('/yourlib/Xerces-C++/lib/libxercesc1_1.a')
command = ADDBNDDIRE BNDDIR(yourlib/libxercesc) OBJ((yourlib/LIBXERCESC *SRVPGM) ) |  |  |  |  |  | 
Troubleshooting: If you are on a V4R3 system, you will get a bind problem
         'descriptor  QlgCvtTextDescToDesc not found'using Iconv400.
         On V4R3 the system doesn't automatically pick up theQSYS/QLGUSRservice
         program for you when resolving this function. This is not the case on V4R4.
         To fix this, you can either manually create the service program after creating
         all the resulting modules in your <OUTPUTDIR> library or you can create
         a symbolic link to a binding directory that points to  theQLGUSRservice program and then specify  an additional-L, -lon theEXTRA_LINK_OPTIONSinMakefile.incl.
         See thelnandqarfunction in the gnu utilities. To build for transcoder ICU: 
          Make sure you have an ICUROOTpath set up so that you can
          find the ICU header files (usually/usr/local)Make sure you have created a binding directory (symbolic link)
          in the file system so that you can bind the Xerces-C++ service program
          to the ICU service program and specify that on the EXTRA_LINK_OPTIONSinsrc/Makefile.incl(usually the default is a link
          in/usr/local/lib). Creating AS400 XML parser message file: As specified earlier, the -mMsgFile support on therunConfigureenable the parser messages to be pulled from
         an AS/400 message file. To view the source for creating  the message file
         and the XML parser messages, see the following stream file: |  |  |  |  |  | EDTF <full path to Xerces-C++>/src/util/MsgLoaders/MsgFile/CrtXMLMsgs |  |  |  |  |  | 
In the prolog of CrtXMLMsgsthere are instructions to create
         the message file: 
         Use the CPYFRMSTMFto copy the CL source to an AS/400 source
         physical file. Note that the target source file needs to have record length
         of about 200 bytes to avoid any truncation.Create the CL program to create the message file and add the various
         message descriptionsCall the CL program, providing the name of the message file
         (use QXMLMSGas default) and a library  (this can be any
         library, including any product library in which you wish to embed
         the xml parser) Note that the Xerces-C++ source code for resolving parser messages is
         using by default message file  QXMLMSG, *LIBL.
         If you want to change either the message file name or explicitly qualify the
         library to match your product needs, you must edit the following.cppfiles prior to your build. |  |  |  |  |  | <full path to Xerces-C++>/src/util/MsgLoaders/MsgFile/MsgLoader.cpp
<full path to Xerces-C++>/src/util/Platforms/OS400/OS400PlatformUtils.cpp |  |  |  |  |  | 
Troubleshooting: If you are using the parser and are failing to get any  message text
         for error codes, it may be because of the *LIBLresolution of
         the message file. | 
 
 
 | 
 
 | |  |  |  |  |  |  Building Xerces-C++ on Macintosh |  |  |  |  |  | 
 |  |  | The Xerces-C++ Mac port has the key following attributes:
		 
			Built atop CoreServices APIs and a limited number of Carbon APIs;
			supports builds for both Mac OS Classic, Carbon, and Mac OS X systems.
			Has a Mac OS native transcoder that utilizes the built-in Mac OS Unicode
			converter [MacOSUnicodeConverter].
			Has a Mac OS native netaccessor that utilizes the built-in Mac OS URLAccess
			routines [MacOSURLAccess].
			Supports builds from Metroworks CodeWarrior, Apple Project Builder,
			and Mac OS X shell.
			 | |  |  |  |  |  |  Using Xerces-C++ with CodeWarrior |  |  |  |  |  | 
 |  |  | Xerces-C++ and CodeWarrior:
			 Xerces-C++ may be built with CodeWarrior under Mac OS Classic or Mac OS X. Since
			the Xerces-C++ code contains some files with very long names, and CodeWarrior
			does not yet support use of files with such long names, the installation
			in this case is somewhat involved.
			 Installing Xerces-C++ for use with CodeWarrior:
			 For compatibility with CodeWarrior, it is necessary to adjust some of the
			file names (and referencing include statements). To do this, it is necessary
			to perform the following steps on a unix (or Mac OS X) machine that
			has support for long file names (a Windows machine may also work):
			 
				Retrieve Xerces-C++ from CVS, or untar a packaged build. Note that these
				steps should not be performed in a Classic Mac OS environment, as file
				names would then be mangled at this point!
				Xerces-C++ comes with a tool that will shorten file names as appropriate,
				and fix up referencing include statements. Duplicate the file
				Projects/MacOS/ShortenFiles.pl to the xercesc main directory (the same
				directory that contains the Projects directory). Executing this perl
				script from this location will create a new directory MacSrc that
				contains patched up versions of files from the src directory.
				 |  |  |  |  |  | cd <xercescroot>
cp Projects/MacOS/ShortenFiles.pl .
perl ShortenFiles.pl |  |  |  |  |  | 
				The source files will likely not now have proper Mac OS type/creator
				attribution. CodeWarrior badly wants this to be correct. So set the
				type/creator of these files somehow. The following should work from
				Mac OS X (but if you're not going to keep building on a Mac OS X
				machine, you may well need to perform this step in some other way once
				you get the files onto your classic machine).
				 |  |  |  |  |  | find . \( -name "*.c" -or -name "*.h" -or -name "*.cpp" -or -name "*.hpp" -or \
-name "*.xml" \) -print0 | xargs -0 /Developer/Tools/SetFile -c CWIE -t TEXT |  |  |  |  |  | 
				Move the entire directory structure to your Mac OS machine.
				 Building Xerces-C++ with CodeWarrior:
			 
				Run CodeWarrior (tested with latest CW Pro 7.0).
				Import the project Projects/MacOS/CodeWarrior/XercesLib/XercesLib.mcp.xml,
				saving it back out to the same directory as XercesLib.mcp.
				This project contains five build targets that build all combinations of
				classic, carbon, debug, and release versions, with an all target that
				builds all of these. Build any or all of these.
				 Building Xerces-C++ Samples with CodeWarrior:
			 A CodeWarrior project is included that builds the DOMPrint sample. This may
			be used as an example from which to build additional sample projects. Please
			read the following important notes:
			 
				Once again, it is required that you import the .xml version of the project
				file, and save it back out.
				The Xerces-C++ sample programs are written to assume a command line interface.
				To avoid making Macintosh-specific changes to these command line programs,
				we have opted to instead require that you make a small extension to your
				CodeWarrior runtime that supports such command line programs. Please read
				and follow the usage notes in XercesSampleSupport/XercesSampleStartupFragment.c.
				 | 
 
 
 
 | |  |  |  |  |  |  Special usage information for Xerces-C++ on the Macintosh |  |  |  |  |  | 
 |  |  | File Path Specification Apart from the build instructions, above, the most important note
			about use of Xerces-C++ on the Macintosh is that Xerces-C++ expects
			all filename paths to be specified in unix syntax. If running natively
			under a Mac OS X system, this path will be the standard posix path as 
			expected by the shell. The easiest means of creating and interpreting these
			paths will be through the routines XMLCreateFullPathFromFSRefandXMLParsePathToFSRefas declared in the fileMacOSPlatformUtils.hpp. FSSpec variants of these routines are
			also supplied. Mac OS Version Compatibility Xerces-C++ requires that several key components of the Mac OS
			be relatively up to date. It should be readily compatible with any system
			above Mac OS 9.0. Compatibility with earlier systems may perhaps be achieved
			if you can install appropriate components.
			 Required components are:
			 
				Unicode Converter and Text Encoding Converter. These provide the base
				transcoding service used to support Xerces-C++ transcoding requirements.
				 Optional components are:
			 
				URLAccess. Provides NetAccessor support to Xerces-C++ for use in
				fetching network referenced entities. If URLAccess is not installed, any
				such references will fail; the absence of URLAccess, however, will not
				in itself prevent Xerces-C++ from running.
				Multiprocessing library. Provides mutual exclusion support. Once again,
				the routines will back down gracefully if Multiprocessing support is not
				available.
				HFS+ APIs. If HFS+ APIs are available, all file access is performed
				using the HFS+ fork APIs to support long file access, and to support
				long unicode compliant file names. In the absence of HFS+ APIs, classic
				HFS APIs are used instead.
				 | 
 
 | 
 
 | 
 |