[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 `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
CFLAGS.optimize
CFLAGS.debug
CFLAGS.profile
CFLAGS.DLL
-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
accomodate this, there are a number of variables that contain the equivalent
of required switches for currently selected compiler. They are summarized
below.
CFLAGS.@
CFLAGS.D
CFLAGS.I
#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
LFLAGS.optimize
LFLAGS.debug
LFLAGS.profile
LFLAGS.DLL
LFLAGS.EXE
LFLAGS.CONSOLE.EXE
Also there are variables similar to `CFLAGS.*' which tell the linker how to link with an additional library and so on.
LFLAGS.@
LFLAGS.L
LFLAGS.l
If your driver, application, or library requires specific C/C++ compiler flags, linking flags, libraries, the usual naming convention is the following:
CFLAGS.name
LFLAGS.name
LIBS.name
DEP.name
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)~/include LIBS.PINGPONG = $(LFLAGS.L)~/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 DOS, OS/2 and 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 accomodate these differences, several variables are used where appropiate, as summarized below.
EXE
O
LIB
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 would 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] | [ ? ] |