Language:

The Free and Open Productivity Suite
Apache OpenOffice 4.1.4 released

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

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.

General Macros Used in makefile.mk
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.

Macros for Generating Object Files and Libraries
Macro Functional Description
OBJFILES=$(OBJ)$/file1.obj $(OBJ)$/file.obj
SLOFILES=$(SLO)$/file1.obj $(SLO)$/file.obj
You must set this macro to generate the appropriate object files from the following source files:
  • file1.cxx
  • file2.cxx

This macro ensures that the build process creates the object files for the compiler in the obj or slo directory of the output tree. On Linux, Solaris, and Mac OS X, this creates dummy .obj files as well as the .ofiles in the obj directory.

You can use these targets can be used to compile C and C++ sources found in different locations. See the rules.mk file for details.

The build process usually creates a library from the object files in the lib subdirectory of the output tree. The name of this library is the value of the $TARGET variable. On Linux, Solaris, and Mac OS X the libraries are dummy libraries containing only the names of the dummy .objfiles.

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.

Macros for Generating 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:

SRCTARGET = $(SRS)$/$(TARGET).srs

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.

Macros Used for Generating 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.

Macros Used for Generating Shared Libraries or DLLs
Macro Functional Description
SHLxTARGET Indicates the filename of the shared library.

In Win32, shared libraries are always built as $(shlxtarget).dll and are created in the bin directory of the output tree.

In UNIX, shared libraries are built as lib$(shlxtarget).so and are located in the lib directory of the output tree.

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:

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.

Special Settings Files for Makefiles
Makefiles Description
unitools.mk This file defines macros for tools which are available on different platforms, for example:
  • AWK
  • COPY
  • FIND
  • TYPE
  • TOUCH
[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
(os2.mk, wnt.mk, unx.mk)
These makefiles specify platform-dependent characteristics, for example:
  • CC
  • LINK
  • LIB
  • FLAGS
  • LINKFLAGS

Other platform-specific makefiles may also exist. For example:

  • unxsols2.mk
  • unxlngi4.mk

These files typically contain variables which are used to change the build:

  • CDEFS general compiler defines (C/C++)
  • CFLAGS general compiler flags (C/C++)
  • CFLAGSCC extra C-only compiler flags
  • CFLAGSCXX extra C++ only compiler flags

In addition there are flags enabled for profiling or debug builds:

  • CFLAGSPROF
  • CFLAGSDEBUG
    The typical value for Linux, Solaris, and Mac OS X platforms for CFLAGSDEBUG is -g.

There are corresponding linker flags for profiled and debug builds:

  • LINKFLAGSPROF
  • LINKFLAGSDEBUG

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:

  • CFLAGSOBJGUIST GUI, object, single-threaded
  • CFLAGSOBJCUIST CUI, object, single-threaded
  • CFLAGSOBJGUIMT GUI, object, multithreaded
  • CFLAGSOBJCUIMT CUI, object, multithreaded
  • CFLAGSSLOGUIMT GUI, object, multithreaded
rules.mk This files specifies the rules for compiling the following types of file:
  • .asm
  • .c
  • .cxx
  • .idl
  • .dpc

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:

  1. Expansion of the overall targets.
  2. Dependency order.
  3. 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.

Macros for Setting Special 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:

  1. Add the targets to the target all as dependencies.
  2. End the list of targets with ALLTAR.
  3. Make sure target all precedes the include of target.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:

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.mkdirective.

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.


Apache Software Foundation

Copyright & License | Privacy | Contact Us | Donate | Thanks

Apache and the Apache feather logo are trademarks of The Apache Software Foundation. OpenOffice, OpenOffice.org and the seagull logo are registered trademarks of The Apache Software Foundation. Other names appearing on the site may be trademarks of their respective owners.