[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.2.2 Variable Naming Conventions

For maximum flexibility (the makefile system should be usable by any compiler on any platform). `cs.mak' avoids any direct references to compiler switches, tool names and so on. Instead there are a number of variables (some of which have default values, but can be changed by submakefiles) which should be used by `cs.mak' as well as by submakefiles, if possible.

The main "tool" used to build Crystal Space is, naturally, the C++ compiler. The variable name for C++ compiler is `CXX'. There are also places where the plain C compiler is required; it is referenced by the `CC' variable. The flags for the C/C++ compilers (it is assumed they both understand same command-line flags) are collected from a number of additional variables, as summarized below.

CFLAGS.GENERAL
General flags used in all compilation modes.
CFLAGS.optimize
Flags used in optimize mode.
CFLAGS.debug
Flags used in debug mode.
CFLAGS.profile
Flags used in profile mode.
CFLAGS.DLL
Flags used when compiling object files for dynamically-linked libraries (i.e. -fpic).

The submakefiles also often need to know how to tell something to C/C++ compiler. For example the path to some system-dependent include files or libraries, or how to define a macro, and so on. The GNU C++ compiler, for example, uses the -Ipath form to define a include path; the Watcom-C compiler, on other hand, uses the -i=path form. To accommodate this, there are a number of variables that contain the equivalent of required switches for currently selected compiler. They are summarized below.

CFLAGS.@
Flag to define the output file name. The default (for Unix-like C compilers) is `-o $@'.
CFLAGS.D
Flag to define a C-preprocessor macro. The default is `-D'.
CFLAGS.I
Flag to specify an additional search path for #include directives. The default equivalent is `-I'.

The linker is referenced through the variable $(LINK). There are also a number of variables that defines linker flags. They are summarized below.

LFLAGS.GENERAL
General linker flags.
LFLAGS.optimize
Flags used in optimize mode.
LFLAGS.debug
Flags used in debug mode.
LFLAGS.profile
Flags used in profile mode.
LFLAGS.DLL
Flags used when building a dynamically loaded plug-in module.
LFLAGS.EXE
Flags used when building a executable.
LFLAGS.CONSOLE.EXE
Flags used when building a console executable (for example, `map2cs'). Some platforms, such as MacOS/X, differentiate between a "graphics" executable and a "console" executable.

Also there are variables similar to `CFLAGS.*' which tell the linker how to link with an additional library and so on.

LFLAGS.@
Define output file name to `$@'. The default is `-o $@'.
LFLAGS.L
Define an additional library search path. The default is `-L'.
LFLAGS.l
Add a library for linking. The default is `-l'.

If your plugin, application, or library requires specific C/C++ compiler flags, linking flags, libraries, the usual naming convention is the following:

CFLAGS.name
Additional C/C++ flags.
LFLAGS.name
Additional linking flags.
LIBS.name
Additional libraries.
DEP.name
Additional dependencies.

For example, suppose your application, which is called Ping-Pong, requires specific compilation flags, as well as dependencies (it depends on several Crystal Space libraries) and extra libraries (suppose you link with an additional `libpingpong.a'). In this case the variables would be named like this:

 
CFLAGS.PINGPONG = $(CFLAGS.I)/usr/local/include/pingpong
LIBS.PINGPONG = $(LFLAGS.L)/usr/local/lib $(LFLAGS.l)pingpong
DEP.PINGPONG = $(CSSYS.LIB) $(CSUTIL.LIB)

Another issue is that several types of files use different extensions on different platforms. For example, executable files on Unix typically have no extension, whereas on Windows they typically have an `.exe' extension. As another example, object files have an `.o' extension on Unix and an `.obj' extension on Windows. To accommodate these differences, several variables are used where appropriate, as summarized below.

EXE
Typical extension for executables (ex: `.exe').
O
Typical extension for object files (ex: `.o'; usage: `pingpong$O').
LIB
Typical extension for libraries (ex: `.a' or `.lib').
DLL
Typical extension for dynamically loaded libraries (`.so' or `.dll').

Also on Unix systems libraries usually have the `lib' prefix, (i.e. the `csutil' library would typically be named `libcsutil.a'). On other systems this is not the case; to resolve this problem a variable called `LIB_PREFIX' is used. It is either set to `lib' or it is empty depending upon the environment. Back to the example, if the submakefile needed to define the rule to build `libpingpong.a', it could be done in this fashion:

 
PINGPONG.LIB = $(LIB_PREFIX)pingpong$(LIB)

If we wanted to build a dynamic library, the name of target would be:

 
PINGPONG.DLL = pingpong$(DLL)

As you can observe, the name of target variables also has a naming convention of its own. If the target is a static library, it is typically named `NAME.LIB'; if it is a dynamic library, it is called `NAME.DLL'; if it is an executable, it is typically named `NAME.EXE'.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

This document was generated using texi2html