After you have set up the build environment, you can run a C compiler to build any of the components.
You must make the compiler define some pre-processor symbols. For a
command-line compiler, this is normally done with a
"-Dsymbol=value" option. The symbols you
need to define are:
| Symbol | Value | Meaning |
|---|---|---|
TiNGTYPE_LINUX | anything | Use only on Linux Indicates that the component should be built for Linux |
TiNGTYPE_QNX | anything | Use only on QNX Indicates that the component should be built for QNX |
TiNGTYPE_WINNT | anything | Use only on Windows 2000 / XP Indicates that the component should be built for Windows |
_WIN32_WINNT | 0x400 | Use only on Windows 2000 / XP Indicates that the component can use facilities introduced in Windows NT 4 (only needed for SignalObjectAndWait() in libutil/WINNT/pthread.c) |
_REENTRANT | anything | This symbol indicates that you are building a multi-threaded program. |
Additionally, you may define:
TiNG_TRACE | 0 | No API tracing is possible. |
| 1 | (default) Normal API tracing is possible. | |
STATIC | static or empty
| The static keyword has two meanings
in C. It can be used to limit scope of an identifier
which would otherwise be global, and it can be used
to extend the lifetime of an object which is local to
a function and would otherwise be destroyed when the
function returns. For debugging it may be useful to
make all statics be global while not affecting object
lifetimes. To allow this, where
static would be used to limit scope, the
identifier STATIC is used instead. Then
if you want to make all the static declarations be
global, you can define STATIC to be
empty.
|
You need to set the list of include directories for the compiler to search. These are the directories which may be required:
| Directory | required for |
|---|---|
| $(TiNG)/include | all Prosody functions |
| $(TiNG)/include/libutil/WINNT | most test programs on Windows |
| switch/include | switch driver functions |
| call/include | call control functions |
For a command-line compiler, this is normally done with a
"-Idirectory" option.
You can safely set the list of
include directories to be all of the above even if some are not
necessary for the application you are building.
You will also need to use the correct options to select a multithreaded program. It is not essential for every program to be multithreaded, but since many are, it's much easier to build everything as multithreaded rather than build a single threaded library and a multithreaded library and use different options for each program depending on which it is.
You also need to find out what needs to be built. Look in the
Makefile for the target operating system in each
directory.
For example, if you want to build everything in the
$(TiNG)/apilib directory, look in
$(TiNG)/apilib/LINUX_V6/Makefile.inc,
$(TiNG)/apilib/WINNT_V6/Makefile.inc, as appropriate and the files
you need to build are those described by the target
"all-$(TiNGTARGET):".
If you need to build a program (rather than just object files), you
will see that each program is described in the Makefile. For example,
in the test/ansplay directory's Makefile for Linux, you will
find that ansplay is described by:
gen-$(TiNGTARGET)/ansplay: ../../gen/version.i gen/ansplay.args.i $(LINK_OBJS) $(LINK) $(LINK_OBJS) -lpthread $(LIBS) $(LIBS_COMMON) $(LIBS_SW) $(LIBS_CL) 2>&1 | t0 errs/$@
so you can see the linker options required. The list of files is
derived from two files: objlist and
LINUX_V6/objlist. Each contains a list of items required, one
per line, with the first column indicating where the item it to be
found and the second column naming the item. These files are
processed by $(TiNG)/libutil/obj2make.pl to generate
suitable parts for the Makefile. Here's the main objlist
file for ansplay:
. ansplay.o Testlib cardlist.o Testlib checkplay.o Testlib errcode_sm.o Testlib error.o Testlib fmtcode.o Testlib modlist.o Testlib watchl1.o apilib call libutil bfile.o libutil bfopen.o libutil vseprintf.o switch
which shows you the list of object files you need to link. The lines
'call' and 'switch' show that the call and
switch libraries are needed, while the other lines refer to object
files within TiNG. If you
follow the build order described in
Prosody installation guide: first time
build and Prosody installation
guide: building software components you will find that everything you
need is always ready by the time you need it.
You should read also Prosody: layout of the distribution which should help you determine where to find the information on what files are used when building each part of the distribution.