Gwyddion uses Subversion version control system for source code revision management. The organisation of the repository is described on project web pages. For example the current head revision of the program itself can be checked out with
svn checkout http://svn.code.sf.net/p/gwyddion/code/trunk/gwyddion
The repository does not contain any generated files, no matter how exotic tools may be necessary to generate them. Therefore, additional packages are required for building from a fresh checkout. There are also certain platform limitations. The additional tools and packages required for development are essentially the same as for compilation from Subversion checkout. More precisely, to build from a fresh checkout all the additional tools are necessary, whereas development may require only a subset of them or even none, depending on the type and extent of the changes in the source code.
Additional development build dependencies:
After a fresh checkout, run ./autogen.sh with
any arguments you would give to configure.
Note it automatically adds options --enable-maintainer-mode
and --enable-gtk-doc to ensure the rules for creation and
updates of various files are active. Generally, you should always use
--enable-maintainer-mode if you intend to change the
program source code in a non-trivial way.
On some systems, autogen.sh can fail even if you have sufficient versions of autotools installed. These systems do not install general autoconf or automake commands, only versioned commands such as autoconf261 or automake19. This makes it particularly difficult to find for example “automake 1.9 or newer” with no limit on how newer it can be. Therefore, autogen.sh does not attempt this at all. You can either create unversioned symbolic links to the versioned commands or run autogen.sh as follows:
AUTOCONF=autoconf261 AUTOHEADER=autoheader261 ./autogen.sh
You may need to set the following variables:
ACLOCAL,
AUTOCONF,
AUTOHEADER,
AUTOM4TE,
AUTOMAKE,
LIBTOOLIZE.
In addition, some operating systems may install
autoconf macros in a place
aclocal does not find them by default. This can
be fixed by setting variable ACLOCAL_FLAGS to give
aclocal additional search paths:
ACLOCAL_FLAGS="-I /usr/local/share/aclocal" ./autogen.sh
It is often necessary to combine these adjustments. For instance on FreeBSD, where all tools are versioned, one typically invokes (broken to lines for easier reading):
AUTOCONF=autoconf261 \
AUTOHEADER=autoheader261 \
AUTOM4TE=autom4te261 \
AUTOMAKE=automake19 \
ACLOCAL=aclocal19 \
ACLOCAL_FLAGS="-I /usr/local/share/aclocal" \
CPPFLAGS=-I/usr/local/include \
LDFLAGS=-L/usr/local/lib \
./autogen.sh --prefix=...
If autogen.sh passes you can compile the program as usual.
Since the standard method to create MS Windows executables is cross-compilation in Linux the recommended method to develop for MS Windows is also to compile in Linux. This can be done either on a different physical computer using ssh or in a virtual machine running on the same computer as the host MS Windows system. In both cases the Gwyddion build directory (and other directories) can be shared between the Linux and MS Windows systems using either Samba or a shared directory mechanism of the virtual machine and the compiled executables thus can be directly tested in MS Windows without having to transfer files back and forth.