### Compiling and Linking Your Application

The make utility helps you manage your software development projects and the files associated with your project. Make uses a makefile to convert your source code file into an object file. The makefile is a special file containing a list of tasks that you provide to convert your source file.

The following example shows the Hello World version 1 makefile for the Windows and OS/2 operating systems.

The Windows makefile is as follows:

    # Make file assumptions:
    #    - Environment variable INCLUDE contains paths to:
    #       IBM Compiler target_directory\include;
    #       IBM Developer's Toolkit target_directory include paths
    #    - Environment variable LIB contains paths to:
    #       IBM Compiler target_directory\lib;
    #       IBM Developer's Toolkit target_directory lib paths
    #    - Current directory contains source files. Originals are in:
    #        IBM Compiler target_directory\samples\ioc\hello1
    #    - current directory will be used to store:
    #        object, executable, and resource files

    # --- Tool defintions ---
    ERASE=ERASE
    GCPPC=ICC
    GLINK=ICC
    GRC=IRC
    GRCV=CONVRC
    GIPFC=IPFC
    GHCW=HCW
    GIPFCVIEW=IVIEW
    GIMAGE=IBMPCNV

    # --- Tool flags ---
    ICLCPPOPTS=/Gm+ /Gd+ /Gh+ /Ti+ /Fb+ /Q+ /Su4
    GCPPFLAGS=$(LOCALOPTS) $(ICLCPPOPTS)
    GCPPLFLAGS=/Tdp /B"/pmtype:pm /debug:none /browse"
    GPERFOBJ=cppwpa3.obj
    GRCFLAGS=-DIC_WIN
    GRCVFLAGS=
    GIPFCFLAGS=/q
    GHCWFLAGS=/c /e
    GIMAGEFLAGS=

    # --- Body ---
    all:  hello1.exe

    hello1.exe:  ahellow1.obj ahellow1.res
          $(GLINK) $(GCPPLFLAGS) $(GCPPFLAGS) /Fe"hello1.exe" \
          ahellow1.obj $(GPERFOBJ) ahellow1.res

    ahellow1.obj:  ahellow1.cpp ahellow1.h
          $(GCPPC) /C+ $(GCPPFLAGS) ahellow1.cpp

    ahellow1.res:  ahellow1.rc ahellow1.h
          $(GRC) $(GRCFLAGS) ahellow1.rc

    ahellow1.rc:  ahellow1.rcx
          $(GRCV) $(GRCVFLAGS) ahellow1.rcx ahellow1.rc

    # --- Cleanup ---
    clean:
            -$(ERASE) hello1.exe
            -$(ERASE) ahellow1.obj
            -$(ERASE) ahellow1.pdb
            -$(ERASE) ahellow1.res
    #        -$(ERASE) ahellow1.rc

The OS/2 makefile is as follows:

    # Make file assumptions:
    # - Environment variable INCLUDE contains paths to:
    # IBM Compiler target_directory\include;
    # IBM Developer's Toolkit target_directory include paths
    # - Environment variable LIB contains paths to:
    # IBM Compiler target_directory\lib;
    # IBM Developer's Toolkit target_directory lib paths
    # - Current directory contains source files. Originals are in:
    # IBM Compiler target_directory\samples\ioc\hello1
    # - current directory will be used to store:
    # object, executable, and resource files

    # --- Tool defintions ---
    ERASE=ERASE
    GCPPC=ICC
    GLINK=ICC
    GRC=RC
    GRCV=COPY
    GIPFC=IPFC
    GHCW=HCW
    GIPFCVIEW=VIEW
    GIMAGE=COPY

    # --- Tool flags ---
    ICLCPPOPTS=/Gm+ /Gd+ /Gh+ /Ti+ /Fb+ /Q+ /qrtti=all
    GCPPFLAGS=$(LOCALOPTS) $(ICLCPPOPTS)
    GCPPLFLAGS=/Tdp /B"/pmtype:pm /debug:none /browse"
    GPERFOBJ=CPPOPA3.OBJ
    GRCFLAGS=-DIC_PM -r
    GRCVFLAGS=
    GIPFCFLAGS=/q
    GHCWFLAGS=/c /e
    GICONFLAGS=
    GBMPFLAGS=
    GPTRFLAGS=

    # --- Body ---
    all: hello1.exe

    hello1.exe: ahellow1.obj ahellow1.res
    $(GLINK) $(GCPPLFLAGS) $(GCPPFLAGS) /Fe"hello1.exe" \
    ahellow1.obj $(GPERFOBJ)
    $(GRC) ahellow1.res hello1.exe

    ahellow1.obj: ahellow1.cpp ahellow1.h
    $(GCPPC) /C+ $(GCPPFLAGS) ahellow1.cpp

    ahellow1.res: ahellow1.rc ahellow1.h
    $(GRC) $(GRCFLAGS) ahellow1.rc

    ahellow1.rc: ahellow1.rcx
    $(GRCV) $(GRCVFLAGS) ahellow1.rcx ahellow1.rc

    # --- Cleanup ---
    clean:
    -$(ERASE) hello1.exe
    -$(ERASE) ahellow1.obj
    -$(ERASE) ahellow1.pdb
    -$(ERASE) ahellow1.res
    # -$(ERASE) ahellow1.rc

There are two ways to invoke make, depending on what you name your make
file.

1. If you have a file named "makefile", type the following:

       nmake

2. If you have a file by a different name, for example, makefile.win, type the following:

       nmake -f makefile.win

A successful make generates the files you need for linking and executing. To remove the files you generate, for example if you want to put the sample directory back the way you found it, run the make clean command. The makefiles provided with Hello World samples include a clean section that erases files you generate. The following make clean command is set at the beginning of the Hello World makefiles, to erase the files:

    clean:
            $(ERASE) HELLO1.EXE
            $(ERASE) AHELLOW1.OBJ

### Packaging Your Application

#### Using Compiler Options with the Open Class Library

You can use various compiler options to build your applications or Open Class Library samples.

Use the following options for dynamic linking:

    /Gm+ /Gd+

Use the following options for static linking:

    /Gm+ /Gd-

Note: | When statically linking on OS/2 and Windows, this option automatically pulls in the necessary Open Class Library import libraries On AIX, you must specify the static libraries at link time.

#### Using Reserved Pragma Priority Values

The Open Class Library reserves the use of #pragma priority values in the range of -2147482624 through -2147481600. The C++ compiler reserves the range below that. As a result, avoid using a #pragma priority value less than -2147481599 (this is equivalent to INT_MIN + 2048) to control the order of static object construction in your Open Class Library application.

#### Understanding Open Class Error and Exception Output

Although Open Class is designed to catch as many errors as possible during the compilation and link steps, some errors can only be detected at run time. The classes in Open Class throw C++ exceptions to indicate runtime errors. Errors messages describing the exception can be seen while debugging, or can be seen in trace output sent to STDOUT, STDERR or a queue; trace output is only seen if you have turned tracing on. Your own classes can also throw C++ exceptions and output trace information in the same way, by using classes provided in Open Class.

#### Linking an Application to the Open Class Library

Link your OS/2 or Windows application to the Open Class Library in one of the following ways, depending on your needs:

1. If you are developing an application, use the Open Class import libraries that correspond to each DLL. On OS/2 and Windows, this happens automatically via #pragma library statements. The pragma library directive causes the compiler to insert a special record into the object file that tells the linker to link with the specified library. Open Class header files contain these directives to tell the linker to link against the corresponding libraries.

   You must also link with OS/2, Windows, and AIX files. This compiler import library resolves C++ runtime external references.

   Note: By compiling with the -Gd -Gmt options, the compiler automatically generates the appropriate .lib names in the resulting .obj files. The linker then uses these files without your explicitly listing them. Compiling with -Gn or linking with /NOD will suppress the use of the compiler generated .lib names. You may need to do this if you rebuild the DLLs.

2. If you are delivering an application, you must decide whether to rename the Open Class Library DLLs and ship them with your applicationi or statically link the Open Class Library code directly into your executable. To statically link to the Open Class Library code, use the static object libraries by coding the -Gd- -Gmt compiler options.

   Using this library does not create dependencies on the four DLLs. You must also link your application to OS/2, Windows, and AIX files, which resolves C++ runtime external references.

Note: You must link your application using icc.exe with the -Tdp compiler option.

By compiling with the appropriate -Gd option, the compiler will automatically generate the appropriate .lib names in the resulting .obj files. The linker will then use these files without your explicitly list them.

The following additional rules apply when you build your application with the dynamic libraries, instead of the static object libraries:

1. A DLL using the Open Class Library must link dynamically to the Open Class Library code (that is, you must link with each import library).
2. An .exe using the Open Class Library and calling a DLL that also uses the class library must link dynamically to the Open Class Library (that is, you must link with each import library).
3. An .exe or .dll file should not link both dynamically and statically to the Open Class Library code.

Note: The cpporr36.dll file (on AIX the file is called libvacocres.o) is the resource DLL used by the Open Class Library for resources that we provide (such as tool bar button bitmaps, animated buttons, bitmaps, container direct manipulation icons, and more). Because this file is loaded dynamically, you need the file when your application is statically or dynamically linked.

You can set the environment variable ICLUI_RESLIB or use ICurrentApplication::setResourceLibrary() to change the default name of this DLL.

Link your AIX application to the Open Class Library by specifying either the non-shared (static) or shared libraries at link time. For the static libraries, the letter ns is appended to the filename.

Note: The first four letters of the CCL controls library (CPPOQI36.DLL) should be the same as the first four letters of the UI classes library (CPPOUI36.DLL) in dynamically linked applications. If your application statically links with the CCL controls library, you may also use the first four letters of your executables instead of those of the UI classes library.

Tracing Exceptions
Following Conventions