File: README.git

package info (click to toggle)
swi-prolog 6.6.6-1~bpo70+1
  • links: PTS, VCS
  • area: main
  • in suites: wheezy-backports
  • size: 82,312 kB
  • sloc: ansic: 322,250; perl: 245,822; sh: 6,651; java: 5,254; makefile: 4,423; cpp: 4,153; ruby: 1,594; yacc: 843; xml: 82; sed: 12; sql: 6
file content (105 lines) | stat: -rw-r--r-- 3,170 bytes parent folder | download | duplicates (2)
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
Installing from GIT
-----------------------

Last update: Mar 22, 2010

GIT (git.or.cz/) is the  recommended  way   to  track  the  development,
especially if you plan to maintain a  modified version or want to submit
patches.

To start working,  get  GIT  for  your   platform.  We  use  msysGit  in
MS-Windows.

Downloading
===========

Next, get the SWI-Prolog git. This  takes   a  while the first time, but
subsequent updates will be fast:

	% git clone git://www.swi-prolog.org/home/pl/git/pl-devel.git

If you have the poor luck that  you   are  behind a firewall that blocks
GIT's  default  port  (9418),  you  can    almost   certainly  use  this
alternative. Note however that this is much slower.

	% git clone http://www.swi-prolog.org/home/pl/git/pl-devel.git

Building
========

Building from GIT is close to building   from  the tar archives, but the
GIT source does  *not*  include  generated   files,  in  particular  the
autoconf configure scripts and the generated   manual  files. The script
prepare performs three steps:

	* Initialize the git submodules
	* Create the configure scripts (requires GNU autoconf)
	* Optionally download the manuals (requires curl)

Please run prepare as below after initial download or updating using git
pull. By default, it only  pulls  those   packages  that  appear  in the
default binary distribution.  Using  --all,   it  also  pulls additional
packages, such as the space  (spatial   indexing)  and utf8proc (Unicode
properties and conversions).

	% ./prepare [--all]

Next, continue as described in INSTALL


Branching and patching
======================

If you plan to submit patches, configure  GIT, so it automatically keeps
track of you. Don't use a secret mail address: it will end up on the GIT
web access at http://gollem.science.uva.nl/git/pl.git

	% git config --global user.name "Your Name Comes Here"
	% git config --global user.email you@yourdomain.example.com

It you want to fix something, it is convenient to first start a branch:

	% git checkout -b mybug

Now, hack away and fix it.  If you have a coherent fix, commit it using

	% git commit -a

and add a descriptive message to your   patch, in particular if you want
to submit it.


Submitting a patch
------------------

GIT is very good at structured   handling of distributed development. If
you want to submit a patch, use   git-format-patch to create the content
of an e-mail message. Depending on  the   nature,  send the patch to the
SWI-Prolog mailinglist or bugs@swi-prolog.org.


Updating
--------

If you made no branches and patches, you update to the latest using

	% git pull
	% make distclean
	% ./prepare [--all]
	% ./build	(see using of the build script in INSTALL.notes)

If you have patches, this is slightly  more difficult. You can keep your
history clean using this instead of the simple pull above:

	% git checkout master
	% git pull
	% git checkout mybug
	% git rebase master

Further reading
---------------

	* http://git.or.cz/ (very good introductions)
	* http://wiki.sourcemage.org/Git_Guide (lots of useful HOWTO tips)
	* http://www-cs-students.stanford.edu/~blynn/gitmagic/ (if you
	want to understand GIT)