Release engineering

Migration of existing SVN checkout

The existing checkout of the 'fixes_2_0' branch can be switched to the release tag using SVN command "switch", specifically its first variant (see below). However, it's recommended to build in exported sources, not in checked out version.

~/fpc>>> svn sw --help
switch (sw): Update the working copy to a different URL.
usage: 1. switch URL [PATH]
       2. switch --relocate FROM TO [PATH...]

 1. Update the working copy to mirror a new URL within the
 repository.
    This behaviour is similar to 'svn update', and is the way to move
    a working copy to a branch or tag within the same repository.

 2. Rewrite working copy URL metadata to reflect a syntactic change
 only.
    This is used when repository's root URL changes (such as a scheme
    or hostname change) but your working copy still reflects the same
    directory within the same repository.

Create libgdb.a and or binutils

• If you have problems building recent binutils or libgdb's on any *nix, and the error is related to intl.h or libintl.a, reconfigure using ../<srcdir>/configure --disable-nls (assuming you use a separate builddir)
• Some cygwin hints:
  • ensure you've installed gcc, bison and flex
  • use
    ./configure --disable-ide --disable-libgui --disable-install-libgui
    to configure

General notes about release building

To create a build, you always have to start with compiler from the last previous major release (e.g. 2.0.0 for all 2.0.x and 2.2.0 releases, 2.2.0 for 2.2.x, etc.), or the last previous minor release (i.e. you can use 2.0.2 for building 2.0.4).

OS/CPU specific release engineering

FreeBSD specific Release Engineering

Linux

Get sources, usually done with a command like:

 svn export http://svn.freepascal.org/svn/fpcbuild/tags/release_2_0_2 fpcbuild

Get libgdb for your CPU from ftp://ftp.freepascal.org/pub/fpc/contrib/libgdb/, extract it into fpcbuild/fpcsrc/ preserving pathes. Before building please check for files libiberty.a, libopcode.a and libbfd.a. These files are often installed in directories like /usr/lib. The compiler must not be able to find them! The reason is that otherwise the compiler might use the preinstalled ones instead of the ones you put in the libgdb directory, and the preinstalled ones are not compatible with libgdb.a. If the compiler finds and uses these libraries in /usr/lib, the IDE will crash on any debugging attempt.

Get the most recent docs package from the ftp site, it's called docs-pdf.tar.gz and copy it into the fpcbuild/ directory.

Change into fpcbuild/ and execute

 install/makepack

Building an rpm

To build an RPM, change into fpcbuild and execute

 make rpm

the documentation will be built as well and that requires a working Tex installation. To prevent the documentation from being built, execute

 make rpm NODOCS=1

Building a deb

To build an Debian Package,

- Ensure that you have at least installed the following debian packages: dpkg-dev, fakeroot

- Modify the fpcbuild/install/debian/changelog file adding the following

 fpc (2.0.4-rc1) unstable; urgency=low
 
 * release candidate build
 
-- First Last <mail@address.ext>  Thu, 07 Jul 2006 23:44:00 +0100
 

- change into fpcbuild and execute

 make deb

the documentation will be built as well and that requires a working Tex installation. To prevent the documentation from being built, execute

 make deb NODOCS=1

Darwin (Mac OS X) - Fink

Files

1. fpc.info
2. fpc-doc.info
3. No patch files are required.

Bootstrap Compiler

Building the package is based on a bootstrap compiler. Version 2.0.4 is powerpc and Rosetta emulation only, so only a powerpc bootstrap compiler is needed. With version 2.2 both native i386 and powerpc compilers will be supported (on going work). Separate bootstrap compilers for i386 and powerpc would be possible, but a universal bootstrap compiler has been choosen, since it makes the installation script simpler. The increased filesize (about twice the size of a single separate bootstrap compiler) of the bootstrap compiler is regarded as neglectable compared to the size of the complete source tarball. A reversion of this decision should be doable by well chosen names for the bootstrap compiler tar balls, for example fpc-%v.%m-darwin.bootstrap.tar.bz2, with %m being powerpc and i386. The universal bootstrap compiler is simply created using lipo from the two separate compilers. Although it is possible to use the previous stable release of fpc as a bootstrap compiler, it is better to use the same version, because make cycle will do only two cycles instead of three.

Usually Required Adjustments for New Releases

These fields usually need changes in the file fpc.info (examples from version 2.1.2, a beta version of 2.2):

Version: 2.1.2
Source: ftp://ftp.freepascal.org/pub/fpc/beta/%v/source/fpcbuild-%v.source.tar.gz
Source-MD5: a2ee4db22301cdcbda07185a7b6679b2
Source2: ftp://ftp.freepascal.org/pub/fpc/beta/%v/source/fpc-%v.universal-darwin.bootstrap.tar.bz2
Source2-MD5: ca5e29e3683ff6d5caa491c0adf4635e

The MD5 checksums can be obtained from the error message when fetching the sources with fink or with the terminal command md5sum.

The fpc-doc.info file also needs according changes in the Source and Source-MD5 fields.

History

2.0.4 first version in stable tree (powerpc and Rosetta emulation only)

1.9.8 initial version in unstable tree

Future Plans

1. Version 2.2.x:
   1. native support of powerpc and i386
   2. universal bootstrap compiler
   3. replacement of separate make commands for compiler, rtl, ... by make all
2. lazarus

Source zip generation

Change to a temporary directory and execute

 fpcbuild/install/makesource <release version>

e.g.

 fpcbuild/install/makesource 2.0.2

Documentation building and LaTeX limits

A lot of TeTeX distributions are configured to never use more than a very small amount of memory. The values chosen are more of the 486 era (several MBs, while now 256MB is considered "entry level").

The Free Pascal documentation is fairly large, and uses a lot of labels for convenient hyperlinked PDFs and thus hits this limit.

This can be remedied by modiying the save_size line in texmf.conf to

 save_size=10000

Usually, you can also do this by environment variable.

export save_size=10000
pdflatex rtl.tex

Packaging system

See Packaging System and dividing FPC - Lazarus into packages

Testing a release

In general:

1. check all zip/deb/rpm etc files
2. try the installer (if available)
3. make sure readme.txt & whatsnew.txt are for the current version
4. run all executables
5. make cycle with newly installed binaries and sources
6. run testsuite
7. IDE
   1. open the installed hello.pp in IDE
   2. make a minor change in the demo in IDE & save it
   3. view documentation in IDE, traverse 2-3 pages (at least one with screenshots)
   4. compile the demo file in IDE
   5. run the demo within the IDE (debugger)
8. Documentation (open all files)
   1. Check PDF documentation (if available)
   2. Check HTML documentation (if available)
   3. Check TXT documentation (if available)

Target-specific:

1. GO32v2
   1. dos???.zip installation
   2. dos???full.zip installation (over the previously installed dos???.zip to simulate updates)
2. OS/2
   1. os2???.zip installation
   2. os2???full.zip installation (over the previously installed os2???.zip to simulate updates)
3. Win32
   1. Run installer
4. x86_64-linux and i386-linux
   1. Test a .rpm install
   2. Test a .deb install
5. darwin (fink)
   1. fink install fpc
   2. fink install fpc-doc