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
  
124
  
125
  
126
  
127
  
128
  
129
  
130
  
131
  
132
  
133
  
134
  
135
  
136
  
137
  
138
  
139
  
140
  
141
  
142
  
143
  
144
  
145
  
146
  
147
  
148
  
149
  
150
  
151
  
152
  
153
  
154
  
155
  
156
  
157
  
158
  
159
  
160
  
161
  
162
  
163
  
164
  
165
  
166
  
167
  
168
  
169
  
170
  
171
  
172
  
173
  
174
  
175
  
176
  
177
  
178
  
179
  
180
  
181
  
182
  
183
  
184
  
185
  
186
  
187
  
188
  
189
  
190
  
191
  
192
  
193
  
194
  
195
  
196
  
197
  
198
  
199
  
200
  
201
  
202
  
203
  
204
  
205
  
206
  
207
  
208
  
209
  
210
  
211
  
212
  
213
  
214
  
215
  
216
  
217
  
218
  
219
  
220
  
221
  
222
  
223
  
224
  
225
  
226
  
227
  
228
  
229
  
230
  
231
  
232
  
233
  
234
  
235
  
236
  
237
  
238
  
239
  
240
  
241
  
242
  
 
HOW TO BUILD PIKE FROM GIT 
 
If you like to live at the bleeding edge you can download Pike from 
git with all the latest additions from the developers.  There are two 
major branches in the archive, the latest stable branch and latest 
development branch.  Stable versions have an even minor version 
number, i.e. 7.0.x, 7.2.x, 7.4.x, whereas the development branches 
have an odd minor version. 
 
Keep in mind that the git versions are under heavy development and 
have not been tested nearly as well as the official releases.  You 
use the code AT YOUR OWN RISK. 
 
 
DEPENDENCIES 
 
Building from git requires the same tools as building from a source 
distribution (gnu m4, bison and a C compiler, suggested also GNU make 
and libz), and then some.  In addition to thosee requirements, you 
need a working Pike, autoconf and gcc (to generate the dependency 
files; another compiler can be used to do the actual compilation). 
 
Not all autoconf versions meet Pike's requirements.  Autoconf version 
2.13 and 2.52 are known to work.  Versions 2.53 through at least 2.57 
are known to not work. 
 
 
CHECKING OUT PIKE FROM GIT 
 
1. Get a recent version of git (1.7.2 or later). 
 
2. Clone the git repository with 
 
         git clone git://pike-git.lysator.liu.se/pike.git 
 
 
The top-level makefile (in this directory, not the src directory) has 
all the magic you need to build Pike directly from git.  Just type 
'make'.  It is preferable to build from the toplevel since it avoids 
contaminating the source tree with object files and other generated 
files. 
 
Other interesting make targets are: 
 
install             Compile and install in default location. 
install_interactive Interactive install. 
tinstall            Test install, i.e. install in build directory. 
verify              Do a test install and run the testsuite with the 
                    installed Pike. 
just_verify         Run the testsuite directly with the Pike binary in 
                    the build tree. 
run_hilfe           Run hilfe without installing Pike. 
pike                Build only the Pike core, do not recurse into the 
                    module directories. 
documentation       Build the reference documentation from the 
                    source.  See the refdoc subdirectory. 
depend              Build the files that tracks dependencies between 
                    the source files.  This is necessary to ensure 
                    correct rebuilding if some of the source files 
                    change, but not if you only intend to use the 
                    build tree once.  It's not run by default. 
source              Prepare the source tree for compilation without 
                    the need for a preexisting installed Pike. 
force_autoconfig    Force a build of the configure scripts.  This is 
                    useful e.g. if a new module directory is added in 
                    the git. 
force_configure     Force configure to be run (recursively). 
reconfigure         Remove the cached results from previous configure 
                    runs and rerun configure recursively. If you have 
                    installed a new library and want Pike to detect it 
                    then the simplest way is to use this target. 
dump_modules        Dump the Pike modules directly in the build tree. 
                    That makes Pike load faster if it's run directly 
                    from there, e.g. through the bin/pike script (see 
                    below).  These dumped modules are not used for 
                    anything else.  After this has been run once, any 
                    changed Pike modules will be redumped 
                    automatically by the main build targets. 
undump_modules      Remove any modules dumped by dump_modules, and 
                    remove the redump step described above. 
force_dump_modules  Force all Pike modules to be redumped, not just 
                    those whose source files have changed. 
snapshot            Create a snapshot export tarball. 
export              Create a source dist and bump up the build number 
                    (if you have git write access).  Please do not 
                    check in the generated files. 
clean               Remove all the built binary files. 
gitclean            Remove all files that are generated automatically, 
                    i.e. bring the tree back to the state as if it 
                    was checked out from the git. 
 
 
CONFIGURE OPTIONS AND BUILD VARIABLES 
 
If you want to pass arguments to the configure script (see below), the 
simplest way is to use the CONFIGUREARGS variable, like this: 
 
    make CONFIGUREARGS="--prefix=/usr/local/my-pike --with-debug" 
 
The arguments passed through CONFIGUREARGS are remembered in the build 
tree and reused if CONFIGUREARGS is undefined or the empty string. 
You therefore don't need to repeat them every time, but you can still 
change them later if you like.  There's a special case for the --help 
argument: If CONFIGUREARGS is set to '--help' then the help text from 
the configure script is shown and nothing else is done, and the stored 
CONFIGUREARGS setting isn't affected. 
 
The build targets also creates a script 'pike' in the bin subdirectory 
which runs the built Pike directly without installing it first.  If 
you want to use Pike this way (which is mainly useful if you update 
from git often), you should consider doing 'make dump_modules' to make 
it start faster. 
 
 
Some options for the configure script are: 
 
--prefix=/foo/bar         if you want to install Pike in /foo/bar, 
                          default is /usr/local. 
--without-gdbm            compile without gdbm support 
--with-rtldebug           compile with runtime debug checks 
--without-cdebug          compile without debug symbols (-g) 
--with-debug              same as --with-rtldebug --with-cdebug 
--without-debug           same as --without-rtldebug --without-cdebug 
--without-copt            compile without -O2 
--without-threads         compile without threads support (see 
                          also the section 'If It Doesn't Work' below) 
--without-zlib            compile without gzip compression libary 
                          support 
--without-dynamic-modules compile statically, no dynamic loading 
                          used (makes the binary larger) 
--without-mysql           compile without mysql support 
--with-profiling          enables profiling Pike code but slows 
                          down interpreter a little 
--with-poll               use poll instead of select 
--with-dmalloc            compile with memory tracking, makes Pike 
                          very slow, use for debugging only. 
 
 
You might also want to set the following environment variables: 
 
CFLAGS     Put extra flags for your C compiler here. 
CPPFLAGS   Put extra flags for your C preprocessor here 
           (such as -I/usr/gnu/include) 
LDFLAGS    Put extra flags to your linker here, such as 
           -L/usr/gnu/lib and -R/usr/gnu/lib 
 
 
MANUAL BUILDING 
 
Instructions if you want to do the build more manually: 
 
1. cd src ; ./run_autoconfig 
   This creates configure files and Makefile.in files. 
 
2. Create a build directory an cd to it.  Do NOT build in the source 
   dir, doing so will make it impossible to do 'make export' later. 
 
3. Run the newly created configure file located in the src dir from 
   the build dir.  Make sure to use an absolute path! This creates the 
   Makefiles you need, e.g. Makefile from Makefile.in and machine.h 
   from machine.h.in.  If you don't use an absolute path the debug 
   information will be all warped... 
 
4. If needed, edit config.h and Makefile to suit your purposes.  We 
   have tried to make it so that you don't have to change config.h or 
   Makefile at all.  If you need to do what you consider 'unnecessary 
   changes' then mail us and we'll try to fit it into configure.  If 
   possible, use gnu make, gcc, gnu sed and bison. 
 
5. Run 'make' 
   This builds Pike. 
 
6. Optionally, run 'make verify' to check that the compiled driver 
   works as it should (might be a good idea).  This will take a little 
   time and use quite a lot of memory, because the test program is 
   quite large.  If everything works out fine no extra messages are 
   written. 
 
7) If you want to install Pike, write 'make install'.  This will put 
   your Pike in <prefix>/pike/<version>/. This way, you can install 
   many Pike versions in parallell on the system if you want to.  To 
   put it below <prefix> directly, as other packages usually do, run 
   'make INSTALLARGS="--traditional" install' instead. 
 
After doing this, DO NOT commit the generated files.  They are placed 
in .gitignore files so you shouldn't have to bother with them. 
 
 
IF IT DOESN'T WORK 
 
 o Try again. 
 
 o Try running 'make depend'. 
 
 o Your sh might be too buggy to run ./configure (this is the case on 
   A/UX).  Try using bash, zsh or possibly ksh.  To use bash, first 
   run /bin/sh and type: 
 
   $ CONFIG_SHELL=full_path_for_bash 
   $ export CONFIG_SHELL 
   $ $CONFIG_SHELL ./configure 
 
 o If you are not using GNU make, compile in the source dir rather 
   than using a separate build dir. 
 
 o ./configure relies heavily on sed, if you have several sed in your 
   path try another sed (preferably gnu sed). 
 
 o configure might have done something wrong, check machine.h and 
   report any errors back to us. 
 
 o Your gmp/gdbm libraries might not be working or incorrectly 
   installed; start over by running configure with the appropriate 
   --without-xxx arguments.  Also note that threads might give 
   problems with I/O and signals.  If so you need to run configure 
   --without-threads. 
 
 o Try a different compiler, malloc, compiler-compiler and/or make 
   (if you have any other). 
 
 
BUGS 
 
If you find a bug in the interpreter, typically if Pike dumps core, 
the first thing to do is to make sure it is compiled with the 
--with-rtldebug configure flag.  If not, reconfigure and recompile 
with that and see if you get another error.  When you've done this, 
please report the bug to us at http://community.roxen.com/crunch/ and 
include as much as you can muster of the following: 
 
  o The Pike version.  (Try pike --version or look in src/version.h) 
  o What kind of system hardware/software you use (OS, compiler, etc.) 
  o The piece of code that crashes or bugs, preferably in a very 
    small Pike-script with the bug isolated.  Please send a complete 
    running example of something that causes the bug. 
  o A description of what it is that bugs and when. 
  o If you know how, then also give us a backtrace and dump of vital 
    variables at the point of crash. 
  o Or, if you found the error and corrected it, just send us the 
    bugfix along with a description of what you did and why.