1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
|
Table of Contents
1) Required software
2) automake/autoconf notes
3) which does what
4) building code
***************************
1) Software required for developers:
In order to compile lifelines from the cvs sources,
the developer needs to have a number of tools available.
make: build process requires gmake
autotools suite: both autoconf and automake (which in turn
require the m4 macro processor) are used to generate
Makefiles and various build files.
bison: Is required to compile lifelines/src/interp/yacc.y.
m4: Is required by the autotools suite as well as for
generation of the default lifelines configuration
prototypes.
perl: Is required to generate the file index.html in the
reports directory, as well as for generation of lines.cfg.
jw: Is used to compile the documentation. It is at least
available in the debian text/docbook-utils package
and the Redhat docbook-utils package. Lack of this tool
is not critical, however, and the make will continue,
only listing these lacks as warnings. The generated
documention is included in both the cvs and src distributions.
This will only prevent regeneration of the documention.
jadetex: Is used to produce pdf versions of the documentation.
It is at least available in the Redhat jadetext package.
See jw above.
lynx: Is used to compile text versions of documentation. See
jw above.
Note: These requirements are for compiling from
the cvs sources, not from a distribution tarball.
Distribution tarballs are built so as not to require
autotools or bison. However, m4 and perl are required.
***************************
2) Some notes about using automake/autoconf:
Many of the files you're used to editing by hand are automatically
generated by automake &/or autoconf. These include any file named
Makefile, Makefile.in, config.h, config.h.in, or configure.
The proper files to modify by hand are configure.ac (if there's something
new you need to determine about the host system at configuration time)
and Makefile.am (if source files are added or removed, targets added,
or dependencies changed).
As long as you have autoconf and automake installed on your system, the
Makefiles generated will be able to regenerate any file dependent on a
Makefile.am or configure.ac. To regenerate the build system explicitly,
sh autogen.sh
The autogen script *must* be run after freshly checking a copy of the
project out of CVS -- the files generated automatically are no longer
included in the CVS repository.
I'm happy to help anyone who needs help adjusting the automake/autoconf
build system to suit your development needs...
Rob Fugina
robf@geekthing.com
(Perry added autogen.sh, 2002.06.04)
***************************
3) Which does what:
At development (or package creation) time, the autogen.sh script
will perform the following 4 steps for you:
1) aclocal: This generates aclocal.m4 from acinclude.m4.
For lifelines aclocal is invoked as
'aclocal -I m4 -I build/autotools'
in order to get all the autoconf, automake and gettext
macros into aclocal.m4.
2) autoheader: This generates acconfig.h.
3) automake: This generates Makefile.in files from Makefile.am files.
4) autoconf: This generates configure from configure.ac.
On remote machine compiling a source distribution package:
configure will generate config.h and Makefile files from Makefile.in files.
4) Building the code
1. check out the code from cvs - there is a link off
http://lifelines.sourceforge.net
which gives instructions for checking out the code. If you're not a
sourceforge developer, you can use the anonymous checkout procedure.
2. For building, refer to the README.MAINTAINERS file and execute the
commands under 'Run autotools:' and 'Build local copy in ./bld subdirectory:'
Note: these commands describe one way to proceed. There are many other
approaches which will also work.
3. The language files po/*.po get updated when you build code; they are also
updated from CVS. If you find that conflicts occur with these files,
you can simply remove them and update them from CVS again. Then your build
should proceed as normal.
4. curses.h. It seems that every distribution places curses.h and
libcurses.so in different places or has slightly different names
for the files. For example, libcursesw.so or libcursesw.a seem the
most prominant versions. If you find that lifelines can't find curses.h
on your system, you can pass in the directory of the file on the configure
step. For example if your curses.h was in /usr/local/ncurses and it wasn't
being found, you could add to the configure step
../configure CPPFLAGS=-I/usr/local/ncurses
|
