This chapter describes compiling, the repeated process that you perform after generating output files with Netscape Extension Builder. Extension code is compiled by running the make command.

• About Compiling the Source Code
• Introduction to Editing Makefiles
• Editing Makefiles on Solaris
• Editing Makefiles On Windows NT
• The make Harness

• If your extension includes additional source code files that were not automatically generated. For example, to support a method stub that you are completing, you might create extra code but place it in a separate file.
• If your extension must link with additional libraries that were not automatically generated.
• If you want to compile or link your extension using additional command-line flags. For example, in the testing phase, you might use the -DVERBOSE flag to generate diagnostic messages while your extension is running.

• Editing Makefiles for C++ Extensions
• Editing Makefiles for Java Extensions

• Adding New Source File Names
• Linking Additional Libraries
• Adding Flags
• Adding Support for Non-Pic Objects

1. Locate the section where SERVICE_SRCS is defined, and append the new file names. For example:
SERVICE_SRCS = \

CExtModule.cpp \

CExtFirstClass.cpp \

CExtSecondClass.cpp \

CMyNewClass.cpp

2. Locate the section where SERVICE_OBJS is defined, and append the name of the corresponding object files. For example:
SERVICE_OBJS = \

$(INTERMEDIATE_OUTDIR_NAME)/CExtModule.o \

$(INTERMEDIATE_OUTDIR_NAME)/CExtFirstClass.o \

$(INTERMEDIATE_OUTDIR_NAME)/CExtSecondClass.o \

$(INTERMEDIATE_OUTDIR_NAME)/CMyNewClass.o

1. Locate the section where LIBS_KIVA is defined.
2. Append your library names to the LIBS_KIVA definition. For example:
LIBS_KIVA += -lMyExtension

1. For C++ compilation flags, edit the CFLAGS definition. For example, to add the DEBUG flag:
CFLAGS += -DDEBUG
2. For link flags, edit the LFLAGS_SERVICE definition. For example:
LFLAGS_SERVICE += -L anotherLibDirectory

LIB_TARGETS += $(LIB_INSTALL_DIR)/lib$(SERVICE_TARGET).so

LIBS_KIVA += FileWriterNOPIC.a -lketgxidl -lketutil \

-lSampleExt_ext

INCLUDE_PATH += -I$(KIVA_EXT_INCLUDE) -I$(INCLUDE_INSTALL_DIR)

# override the default LFLAGS_ZTEXT value

LFLAGS_ZTEXT =

The default value of LFLAGS_ZTEXT is "-z text". This value causes a fatal error whenever text relocations need to occur, and text relocations always occur when linking with a non-PIC object. By overriding the default value of LFLAGS_ZTEXT to nothing, the linker does not use the "-z text" flag. As a result, non-PIC objects can be successfully linked.

1. Locate the section where JAVA_SRCS is defined, and append the new file names. For example:
JAVA_SRCS = \

CExtModule.java \

CExtFirstClass.java \

CExtSecondClass.java \

CMyNewClass.java

2. Locate the section where JAVA_CLASSES is defined, and append the name of the corresponding Java class files. For example:
JAVA_CLASSES = \

$(JAVA_INSTALL_DIR)/$(JAVA_PACKAGEDIR)/CExtModule.class \

$(JAVA_INSTALL_DIR)/$(JAVA_PACKAGEDIR)/ \

CExtFirstClass.class \

$(JAVA_INSTALL_DIR)/$(JAVA_PACKAGEDIR)/ \

CExtSecondClass.class \

$(JAVA_INSTALL_DIR)/$(JAVA_PACKAGEDIR)/CMyNewClass.class

• Editing Makefiles for C++ Extensions
• Editing Makefiles for Java Extensions
• Configuring the make Harness

• Adding New Source File Names
• Linking Additional Libraries
• Adding Flags

1. Locate the section where SERVICE_SRCS is defined, and append the new file names. For example:
SERVICE_SRCS = \

CExtModule.cpp \

CExtFirstClass.cpp \

CExtSecondClass.cpp \

CMyNewClass.cpp

2. Locate the section where SERVICE_OBJS is defined, and append the name of the corresponding object files. For example:
SERVICE_OBJS = \

$(INTERMEDIATE_OUTDIR_NAME)\CExtModule.obj \

$(INTERMEDIATE_OUTDIR_NAME)\CExtFirstClass.obj \

$(INTERMEDIATE_OUTDIR_NAME)\CExtSecondClass.obj \

$(INTERMEDIATE_OUTDIR_NAME)\CMyNewClass.obj

3. Locate the section where INTERMEDIATE_OUTDIR_NAME is defined, and add similar entries for each of the new files. For example:
$(INTERMEDIATE_OUTDIR_NAME)\CMyNewClass.obj: CMyNewClass.cpp

$(CPP) $(CFLAGS) -Fo"$@" CMyNewClass.cpp

1. Locate the section where LIBS_KIVA is defined.
2. Append your library names to the LIBS_KIVA definition. For example:
LIBS_KIVA = $(LIBS_KIVA) ketgxidl.lib ketutil.lib MyExt.lib
3. If the new libraries reside in directories other than those defined by LIB_PATH, append the directory paths to LIB_PATH. For example:
LIB_PATH = $(LIB_PATH); C:\my_legacy_code\lib

1. For C++ compilation flags, edit the CFLAGS definition. For example, to add the DEBUG flag:
CFLAGS = $(CFLAGS) -DDEBUG
2. For link flags, edit the LFLAGS_SERVICE definition. For example:
LFLAGS_SERVICE = $(LFLAGS_SERVICE) -nologo

1. Locate the section where JAVA_SRCS is defined, and append the new file names. For example:
JAVA_SRCS = \

CExtModule.java \

CExtFirstClass.java \

CExtSecondClass.java \

CMyNewClass.java

2. Locate the section where JAVA_CLASSES is defined, and append the name of the corresponding Java class files. For example:
JAVA_CLASSES = \

$(JAVA_INSTALL_DIR)\$(JAVA_PACKAGEDIR)\CExtModule.class \

$(JAVA_INSTALL_DIR)\$(JAVA_PACKAGEDIR)\ \

CExtFirstClass.class \

$(JAVA_INSTALL_DIR)\$(JAVA_PACKAGEDIR)\ \

CExtSecondClass.class \

$(JAVA_INSTALL_DIR)\$(JAVA_PACKAGEDIR)\CMyNewClass.class

3. Locate the section where JAVA_INSTALL_DIR is defined, and add similar entries for each of the new files. For example:
$(JAVA_INSTALL_DIR)\$(JAVA_PACKAGEDIR)\CMyNewClass.class :

CMyNewClass.java

$(JAVAC) $(JAVAC_FLAGS) CMyNewClass.java

# Contains machine-specific directories.

# Where the MSDEV environment is.

# Make sure you keep the double quotes if the

# paths you specify here include spaces.

# For example, "c:\Program Files\DevStudio"

#

WIN_SDK = "c:\msdev"

CPP = "c:\msdev\bin\cl.exe"

LINK = "c:\msdev\bin\link.exe"

WIN_SDK_INCLUDE = "c:\msdev\include"

WIN_SDK_LIB = "c:\msdev\lib"

The installer attempts to set these variables to their correct values. Check the env.mak file and edit these values as needed.

• Invokes the KIDL Compiler to translate IDL files into Java or C++ source files.
• Copies source files into appropriate locations in the code tree.
• Compiles source files.

• Runs the KIDL Compiler on <extension>.idl to produce public interfaces.
• Copies the public interfaces to the appropriate location, depending on whether they are Java or C++.
• For a C++ extension, compiles this source code and puts <extension>_ext.lib in
Windows

<NAS_ROOTDIR>\APPS\extensions\lib

Solaris

<NAS_ROOTDIR>/APPS/bin

• Traverses into each service module subdirectory and runs make, which in turn performs the following tasks:

• Runs the KIDL Compiler on the service IDL file, producing stub files, runtime feature files, Java Access Layer files (if specified in IDL), and accessor files.
• Copies these source files into appropriate locations in the code tree.

• Checks for the existence of a makefile in each <service_module> subdirectory. If no makefile exists, it is copied from gen.<service_module>.
• Traverses into the accessor subdirectory and runs make, which in turn compiles the accessor files.
• Traverses into each _<service_module> subdirectory and runs make, which in turn compiles the code for Netscape Extension Builder runtime features.
• Traverses into each <service_module> subdirectory and runs make, which in turn performs the following tasks:

• Checks for the existence of the stub files. If none are present, they are copied from the gen.<service_module> directory.
• Compiles the stub files. For the initial compile, the stub files are empty. You must complete the method stubs in these files and then recompile.

• Compiles public Java interfaces and Java accessors.
• For Java extensions, checks for the existence of a makefile in each <service_module> subdirectory. If no makefile exists, it is copied from gen.<service_module>.
• For Java extensions, traverses into each _<service_module> subdirectory and runs make, which in turn compiles the code for Netscape Extension Builder runtime features.
• Traverses into each <service_module> subdirectory and runs make. If the extension is written in Java, running make in this directory performs the following tasks:

• Checks for the existence of the stub files. If none are present, they are copied from the gen.<service_module> directory.
• Compiles the stub files. For the initial compile, the stub files are empty. You must complete the method stubs in these files and then recompile.

If the extension is written in C++ and has a Java Access Layer, then running make from the <service_module> directory performs the following tasks:

• Compiles the Java classes with native signatures.
• Runs javah and javah -stubs to produce the Java native interface stubs.
• Compiles the Java native interface stubs and the KIDL-generated native wrapper code.