Makefiles Description
The dmake
tool uses makefile.mk
.
The following sections describe the general structure of
makefile.mk
makefiles.
- General
Structure of
makefile.mk
Makefiles - Generation of Object Files and Libraries
- Generation of Resource Files
- Generation of Applications
- Generation of Shared Libraries or Dynamic Link Libraries
- Internal Structure of the Makefiles
- Setting Additional Options
- Creation of Additional Targets
General
Structure of makefile.mk
Makefiles
The general outline of makefiles is as follows:
PRJ=.. PRJNAME=SW TARGET=core .include:settings.mk # use the predefined macros .include:target.mk |
The following table describes the macros you use in the general outline of a makefile.
Macro | Functional Description |
---|---|
PRJ |
This macro gives the relative position of the root of the current module. |
PRJNAME |
This macro gives the name of the module. This name must be unique within the tree. |
TARGET |
This macro specifies an identifier for the current directory. This
name must be unique within the module, or a filename conflict may occur in
the output or the solver tree. |
Generation of Object Files and Libraries
The following table describes the macros you use to generate object files and libraries. The x in these macros signifies a number between one and nine. This specifies support for up to nine different libraries.
Macro | Functional Description |
---|---|
OBJFILES=$(OBJ)$/file1.obj $(OBJ)$/file.obj |
You must set this macro to generate the appropriate object files
from the following source files:
This macro ensures that the build process creates the object files
for the compiler in the You can use these targets can be used to compile C and C++ sources
found in different locations. See the The build process usually creates a library from the object files
in the |
LIBTARGET=NO |
Set this macro when you do not want to build a library. |
LIBxTARGET=$(LB)$/name.lib |
You can use several library macros of this form to build libraries that do not consist of all object files in a directory or to merge different libraries. |
LIBxARCHIV=$(LB)$/libname.a |
Sets up support for static linking of libraries. Linux, Solaris, and Mac OS X support this macro. |
LIBxOBJFILES |
Specifies object files to bind into linked libraries. |
LIBxFILES |
Specifies further files to link into the linked library. |
Generation of Resource Files
The following table describes the macros you use to generate resource
files. The German language resource files are built by default. To support
other locales, the environment variable UPDATER
must be set
to YES and the corresponding locale environment variable RES_language
must also be set.
The x in these macro names signifies a number between one and nine. This specifies support for up to nine different resource files.
Macro | Functional Description |
---|---|
SRCFILES=file1.src file2.src |
You must set up this macro to generate resource files. To create
one resource file from these files the $(TARGET).srs file is
created in the srs subdirectory of the output tree, for example:
|
SRSxNAMES and SRSxFILES |
You can use these macros to support the building of several srs
files. |
RESLIBxNAME and RESLIBxSRSFILES |
You can use these macros to build resource DLLs. |
You can also set the give_me_all_languages
environment variable
to build resource files for languages. However, this builds resource files
for all languages.
Generation of Applications
The following table describes the macros you use to generate applications. The x in these macro names signifies a number between one and nine. This specifies support for up to nine different applications.
Macro | Functional Description |
---|---|
APPxTARGET |
Indicates the filename of the application. The application is always
built in the bin directory of the output tree. |
APPxOBJS |
Indicates object files that link to the application. Do not use this macro to build objects, as it does not recognize dependencies. |
APPxSTDLIBS |
Indicates import libraries that link to the application. These
are standard binary libraries, such as .a and .so
files. |
APPxLIBS |
Indicates libraries from the same module that link to the application. For UNIX these are simple text lists of object files, rather than normal binary libraries. |
APPxDEF |
Specifies a definition file, if you use one in linking. For Win32 only. |
APPxDEPN |
Specifies dependencies. |
APPxRES |
Specifies system resources. For Win32 only. |
APPxICON |
Specifies an application icon. For Win32 only. |
Generation of Shared Libraries or Dynamic Link Libraries
The following table describes the macros you use to generate shared libraries or dynamic link libraries (DLLs). The x in these macro names signifies a number between one and nine. This specifies support for up to nine different shared libraries.
Macro | Functional Description |
---|---|
SHLxTARGET |
Indicates the filename of the shared library.
In Win32, shared libraries are always built as In UNIX, shared libraries are built as |
UPD and DLLPOSTFIX |
Provide platform and release independent names, for example: bla$(UPD)$(DLLPOSTFIX)
results in bla599mi.dll for release 599 on Windows NT. |
SHLxOBJS |
Specify the object files that are used to create the library. |
SHLxSTDLIBS |
Links import libraries. |
SHLxLIBS |
Specifies libraries from the same module to put into the shared library. |
SHLxDEF |
Specifies the exported symbols file. For Win32 only. |
SHLxDEPN |
Indicates dependencies. |
SHLxRES |
System dependent resources use this macro. |
SHLxIMPLIB |
Specifies an import library to create. For Win32 only. |
DEFxNAME |
Specifies the name of the definition file. This is usually a similar name to the shared library. |
DEFxDEPN |
Indicates definition file dependencies. |
DEFLIBxNAME |
Specifies the library name to parse for symbols. For Win32 only. |
DEFxDES |
A comment on the definition file. |
DEFxEXPORTyy |
A symbol name. The y in this macro name signifies a number from 1-99. |
DEFxEXPORTFILE |
A file of symbols to export. |
The following example shows how you can use these macros:
$(MISC)$/$(SHLxTARGET).flt: @echo string >> $@
Note: The new line and indentation are necessary for these lines to work.
This command generates a filter file for automatically creating a definition
file. The ldump
tool parses the library specified in DEFLIBxNAME
for symbols, removes all symbols that match the string in the *.flt
file, and writes the resulting list into the definition file.
You can only do this for Win32. A similar process for Linux, Solaris, and Mac OS X is planned.
Internal Structure of the Makefiles
Each makefile contains an include directive to a settings.mk
file, followed by an include directive to a target.mk
file.
The following sections describe these files.
The settings.mk
file
The file settings.mk
sets all the global settings for the
makefiles. It sets macros, based on the following:
- The underlying operating system.
- The compiler used.
- The version of the office suite you are building.
For example, it sets the name of the compiler used, linker, or library manager. It can also define the names of libraries, compiler switches, and link switches.
In the target.mk
file, the standard target is predefined
depending on the macros you set. For example, it can contain statements for
linking applications, libraries, or resources. Typically, the include
directive gets these files from solenv/inc
. Typically, the
include directive gets these files from solenv/inc.
There are other makefiles that specify particular settings that control
parts of the build. The following table describes these special settings
makefiles. These makefiles are included by either settings.mk
or target.mk
.
Makefiles | Description |
---|---|
unitools.mk |
This file defines macros for tools which are available on different
platforms, for example:
|
[upd]minor.mk |
Macros such as BUILD and LAST_MINOR are
set in this file. |
libs.mk |
The platform-dependent environment setup for LIBRARIES
is stored in this file. |
platform-name.mk |
These makefiles specify platform-dependent characteristics, for
example:
Other platform-specific makefiles may also exist. For example:
These files typically contain variables which are used to change the build:
In addition there are flags enabled for profiling or debug builds:
There are corresponding linker flags for profiled and debug builds:
There is also support for whether the target is a command-line user interface (CUI) or graphical user interface (GUI), whether it is an object or shared library and whether it is single-threaded (ST) or multi- threaded (MT) by using the following flags:
|
rules.mk |
This files specifies the rules for compiling the following types
of file:
There may be many rules to build each type of file. From these rules, existing source files can build targets. |
The target.mk
file
After the include of settings.mk
, the next major include
is the target.mk
file which describes how to build the targets
of each platform. The target.mk
file is divided into the following
parts:
- Expansion of the overall targets.
- Dependency order.
- Description of the following individual targets:
_tg_def.mk
- the definition files for shared libraries (DLLs)._tg_sdi.mk
- the target definition for the IDL (svidl
) files.tg_obj.mk
- the building of the library from object files.tg_slo.mk
- the building of the library from.slo
files._tg_lib.mk
- the building of the library from any files._tg_srs.mk
- the translation of the.src
files._tg_res.mk
- the translation of the.srs
files._tg_rslb.mk
- generation of the resource DLLs._tg_shl.mk
- generation of the shared libraries.tg_jar.mk
- generation of the jar files.tg_dep.mk
- generation of the dependencies.
The file also includes the descriptions of many further targets such as
killobj
, killbin
, and so on.
Setting Additional Options
You use the macros described in the following table to set additional options.
Makefiles | Description |
---|---|
ENVCFLAGS |
This macro supports additional compiler options for C. |
ENVCXXFLAGS |
This macro supports additional compiler options for C++. |
ENVLINKFLAGS |
This macro supports additional linker options. |
Creation of Additional Targets
The following sections describe ways to create additional targets in a makefile.
Add Targets to all
To build targets other than the default targets that are created by the
target.mk
file, follow these steps:
- Add the targets to the target
all
as dependencies. - End the list of targets with
ALLTAR
. - Make sure
target all
precedes the include oftarget.mk
in the makefile.
If you write your target in a platform independent form without using
any hard-coded pathnames, ensure that your target appears before the .include:target.mk
directive. If this works, this is an acceptable way to create an additional
target.
Adding Targets to a Makefile That Include Targets
The typical way to add a target is to add it to an existing makefile.mk
that already includes targets. This causes the following problems:
- If you place your target before the
.include:target.mk
directive in the makefile, it disables the global targets. - If you place your target after the
.include:target.mk
directive,dmake
does not build the target. - If you try to build your target by using the technique in the following
sample, you may encounter several other problems.
all: \ new-target \
ALLTARThe first target is always built. When doing an initial build,
dmake
enters states where noALLTAR
is defined and displays an error message and stops.There is also no guaranteed order of execution of those two targets. It may work most of the time and produce unusual errors on multiprocessor machines.
Declaring Dependencies Before Adding Targets
Define explicit dependencies as follows:
#this object depends on generated source $(OBJ)$/myobject.obj : $(MISC)$/myobject.cxx |
Then define the target to generate the source file after this statement.
If this object is needed now, there is a dependency on the source file and
the target is executed. You must define all the targets and dependencies
after the .include:target.mk
directive.
There is still a potential problem of conflicts with targets added to the global makefiles in the future. If something in the build environment changes and affects your target, it may be difficult to identify the change.