1 Maxima project Git / build system HOWTO
6 Makefile.am is the file to modify, NOT Makefile
7 (Makefile is generated automatically from Makefile.am)
9 "make install" catches Makefile problems
10 that are not detected by "make" alone
12 Adding / removing files often leads to Makefile problems
14 To update your repository, execute
15 git pull # assuming origin/master points to the SF Maxima repo
18 git pull # update your repo
19 git checkout master # work off master
20 git checkout -b scratch-pad # create a working branch
21 <do development, tests, commits, then, once satisfied...>
22 git checkout master # put yourself on master branch
23 git pull # update your repo, again
24 git merge scratch-pad # merge development work into master
25 git push origin master # push to SF Maxima repo
27 BE SURE NOT TO PUSH YOUR SCRATCH-PAD!
29 2 Renaming something in Git
31 -- Create a scratch/development branch as in 1.
34 This moves X to Y and preserves the history.
35 Like any other change, this needs to be committed
38 3 Adding / removing a file in maxima/src
40 -- Create a scratch/development branch as in 1.
42 -- Add new file X, then execute
43 git add X; git commit -m 'Message' -- X
47 Then execute "git commit" as above
49 -- Add / remove file name from maxima/src/Makefile.am
51 -- Add / remove file name from maxima/src/*-depends.mk
53 NOTE: There are several *-depends.mk files. These are
54 theoretically updated automatically but to the best
55 of my knowledge it is necessary to fix them by hand.
57 -- Add / remove file name in maxima/src/maxima.system
60 "sh bootstrap; ./configure --enable-foolisp; make; make install"
61 and "run_testsuite();" all succeed
63 -- If the change affects the plotting routines: Verify that
64 tests/testbench_draw_manual.wxm still holds the right
67 -- If the change affects drawdf() or plotdf(): Verify that
68 tests/testbench_drawdf_manual.wxm still holds the right
71 -- Merge your work onto master and push the changes as in 1.
74 4 Adding / removing a file in maxima/share
76 -- Copy new file / remove old file
79 -- Add / remove file name in maxima/share/Makefile.am
82 "sh bootstrap; ./configure --enable-foolisp; make; make install"
83 and "run_testsuite();" all succeed
85 -- If the change affects the plotting routines: Verify that
86 tests/testbench_draw_manual.wxm still holds the right
89 -- Merge your work onto master and push the changes as in 1.
92 5.1 Creating a new share package
94 E.g., new package name = my_package
96 -- Naming conventions:
98 write_long_names_like_this, andNotLikeThisPlease,
99 norlikethiseitherthanks
101 spell_out_names, dnt_try_sv_typng_w_abbrvs_tnx
103 -- Create a new directory my_package
105 -- Put Lisp and/or Maxima files in the directory
107 At least one file must be named my_package.lisp or my_package.mac
108 Otherwise load(my_package) fails
110 -- Create texinfo documentation file my_package.texi
111 (PLEASE CREATE DOCUMENTATION, THANK YOU)
113 my_package.texi goes in maxima/doc/info
114 (same as other texinfo files)
116 Use maxima/share/template.texi as a template for my_package.texi
118 -- Create test file rtest_my_package.mac
119 (PLEASE CREATE A TEST FILE, THANK YOU)
121 Test file contains pairs of expressions:
122 input expression, then expected result
124 batch("my_package/rtest_my_package.mac", test);
128 5.2 Adding a directory in maxima/share
130 -- Create a scratch/development branch as in 1.
132 -- Make the new directory and put the new files in it
134 -- Add the all the files in your new directory and commit this change:
136 git commit -m 'Message' -a
138 -- Put the my_package files on the file list of maxima/share/Makefile.am
140 -- Add my_package to SHARE-SUBDIRS-LIST in maxima/src/init-cl.lisp
142 -- Move my_package.texi to maxima/doc/info
144 Put my_package.texi on the list of files in
145 maxima/doc/info/Makefile.am
147 Put my_package on the list of topics in maxima/doc/info/maxima.texi
148 See instructions in comments at top of maxima/share/template.texi
151 "sh bootstrap; ./configure --enable-foolisp; make; make install"
152 and "run_testsuite();" all succeed
154 -- Commit and push your work as in 1.
157 6 Adding / removing a file in maxima/tests
159 -- Create a scratch/development branch as in 1.
161 -- Copy new file / remove old file
162 and execute "git add" / "git rm"
164 -- Add / remove file name in maxima/tests/Makefile.am
166 -- Add / remove file name in maxima/tests/testsuite.lisp
169 "sh bootstrap; ./configure --enable-foolisp; make; make install"
170 and "run_testsuite();" all succeed
172 -- Commit and push your work as in 1.
175 7 Updating the website
177 See the Git repository "website", particularly "README.md" there.
182 All you need is the rsync tool and some disk space.
184 Issue the following command:
186 rsync -av 'rsync://maxima.git.sourceforge.net/gitroot/maxima/*' .
189 8.2 Backups of the ML subscribers list
191 You need to be a list admin to do that. Other then that you only
192 need a mail client to send mailman commands to
193 maxima-request@math.utexas.edu
195 The command to get the subscribers list is "who" followed by the
196 list admin password. Sending an empty mail with "who XXX" in the
197 subject line should be enough.
199 I have the following cron.weekly script to do this automatically:
203 | su myuser -c "echo end | mail -s \"who password\" maxima-request@math.utexas.edu"
208 Backups of the following stuff would be nice too:
219 Releases are prepared (nominally) three times a year, on April 1,
220 August 1, and December 1. Releases simply package whatever seems
223 It is the responsibility of developers (not the release
224 administrator) to copy bug fixes from the release branch to master
225 or vice versa (it doesn't matter whether bug fixes are introduced
226 on one branch or the other).
228 I don't recommend major changes on a release branch, but there is
229 really nothing to stop it. As always I'll appeal to good judgement.
231 If I've forgotten some step, please add it to this document.
233 9.2 Release numbering
235 The first release on the 5.mm release branch is 5.mm.0, the second
236 is 5.mm.1, third 5.mm.2, etc. The highest number on the branch is
237 the "best" or, at least, the most committed-to version. There is no
238 release candidate numbering.
240 The version major number has been 5 for many years. If you feel like
241 changing it to, say, 6, well, there's nothing to stop you.
245 The changelog for 5.mm is named ChangeLog-5.mm.md (the suffix .md
246 indicating that it is in so-called "markdown" format). To obtain the
247 raw material for the changelog:
249 $ git log branch-5.${mm-1}-base..HEAD
251 Use the git-log output as the basis for ChangeLog-5.mm.md. Use your
252 best judgement as to what to include; the git-log output is
253 typically much, much larger than the changelog. Look at previous
254 changelogs to see the markdown format and organization.
256 Commit ChangeLog-5.mm.md to master. Don't forget to add it to
257 the top level "Makefile.am" so that it will be included in the
260 9.4 Git commands for releases
262 Release versions live on a branch named branch-5_mm, and are tagged
263 5.mm.0, 5.mm.1, 5.mm.2, etc. The Git tag must be the same as the
264 version number declared to autoconf.
266 $ git checkout master
267 $ git tag -a branch-5_mm-base
268 $ git push --tags origin master
269 $ git checkout -b branch-5_mm
270 $ <edit configure.ac to set version number to 5.mm.0>
271 $ git add configure.ac && git commit
274 <at this point, verify that you can build packages BEFORE you push>
276 $ git push --tags origin branch-5_mm-base
277 $ git checkout master
278 $ <edit configure.ac to set version number to 5.${mm-1}post>
279 $ git add configure.ac && git commit
280 $ git push origin master
282 Repeat 5.mm.0 stuff (edit configure.ac and tag) for 5.mm.1, 2, 3, ....
284 To copy bug fixes from one branch to another:
286 $ git cherry-pick -x <commit hash>
288 9.5 Building a release
290 $ git checkout branch-5_mm
295 At this point you now have maxima-5.mm.nn.tar.gz.
297 Binaries for Linux are traditionally created by RPM.
299 I'll assume you know how to build stuff with RPM. Copy the tar.gz
300 to <path to rpm build tree>/SOURCES/. Then:
302 $ rpmbuild -ba maxima.spec
304 Debian packages can be built the following way:
306 - Install clisp, sbcl, gcl, ecl and debhelper.
307 - checkout the branch DebianPackaging
308 - Update the changelog contained in its debian directory: From there the
309 e-mail address of the packager and the version number of the Debian
310 package are taken. It also is important that gpg knows the private key
311 for the e-mail address mentioned in the last ChangeLog entry.
312 - copy the debian directory into the directory containing the contents of
314 - cd into this directory and type:
316 - debuild will now complain that the source is missing and tell under which
317 names it will accept the tarball. Rename the tarball to this name and start
319 - a few minutes later gpg will ask for the key's password in order to sign
320 the newly built packages.
322 Unfortunately just using the Debian package included in the autotools won't
323 equip the Maxima package it generates with the metadata that allows to
324 install the wxMaxima package shipped with Debian and Ubuntu.
328 $ sftp mysfusername,maxima@frs.sourceforge.net
329 > cd /home/frs/project/m/ma/maxima
331 > mkdir 5.mm.nn-Linux
334 > put maxima-*5.mm.nn*.rpm
336 > mkdir 5.mm.nn-source
338 > lcd /path/to/tar.gz
339 > put maxima-5.mm.nn.tar.gz
344 Post an announcement about every 5.mm.nn release to the Maxima
345 mailing list. When it seems stable enough (i.e. no immediate plans
346 to create another release) feel free to announce it in other forums,
349 Since wxMaxima does do a simultaneous release with Maxima and
350 windows installers containing wxMaxima and maxima are usually
351 published within hours of the new Maxima release the wxMaxima
352 developers beg to be informed in advance about the planned release
353 date. Filing a ticket at http://andrejv.github.com/wxmaxima/
354 or sending the project maintainer an email should be sufficient