[ < ] | [ > ] | [ << ] | [ 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 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
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
accommodate 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 plugin, 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)/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
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 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] | [ ? ] |