Gwyddion utilise le système de contrôle de version Subversion pour la gestion des modifications du code source. L'organisation de ce dépôt est décrit sur la page web du projet. La dernière révision peut ainsi être contrôlée avec
svn checkout http://svn.code.sf.net/p/gwyddion/code/trunk/gwyddion
Le dépôt ne contient aucun fichier généré, quels que soient les outils nécessaires pour les générer. Des paquets additionnels peuvent donc être nécessaire, et il peut aussi y avoir des limitations liées aux plateformes utilisées. Les outils et paquets additionnels nécessaires pour le développement sont les mêmes que pour la compilation à partir de la dernière révision Subversion. Plus précisément, il vous faudra tous les outils pour compiler une révision, alors que le développement ne nécessitera qu'une partie de ceux-ci, ou même aucun, en fonction du type et de l'importance des modifications.
Dépendances de compilation supplémentaires :
Après avoir importé la dernière révision, lancez
./autogen.sh avec tous les arguments que vous
donneriez à configure. Notez que cela ajoute
automatiquement l'option --enable-maintainer-mode et
--enable-gtk-doc pour activer les règles de création et
de mise à jour de différents fichiers. De manière générale, il faut
toujours utiliser --enable-maintainer-mode lorsque vous
souhaiter ajouter une modification au programme.
Sur certains systèmes autogen.sh peut échouer même si les versions des autotools installés sont suffisamment récentes. Certains systèmes d'exploitation n'installent pas les commandes autoconf ou automake, seulement des commandes versionnées telles que autoconf261 ou automake19. Il peut ainsi être difficile de trouver par exemple « automake 1.9 ou plus » et donc autogen.sh ne le cherchera pas. Vous pouvez soit créer des liens symboliques non versionnés vers les commandes versionnées ou lancer autogen.sh de la manière suivante :
AUTOCONF=autoconf261 AUTOHEADER=autoheader261 ./autogen.sh
Il vous faudra peut-être définir les variables suivantes :
ACLOCAL,
AUTOCONF,
AUTOHEADER,
AUTOM4TE,
AUTOMAKE,
LIBTOOLIZE.
De plus, certains systèmes d'exploitation peuvent installer les macros
autoconf à un emplacement que
aclocal ne pourra trouver par défaut. Ceci peut être
corrigé en définissant la variable ACLOCAL_FLAGS de
manière à donner des chemins supplémentaires à
aclocal :
ACLOCAL_FLAGS="-I /usr/local/share/aclocal" ./autogen.sh
Il est souvent nécessaire de combiner ces modifications. Par exemple sous FreeBSD, où tous les outils sont versionnés, il faudra ajouter (la ligne complète est décomposée pour faciliter la lecture) :
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=...
Si autogen.sh réussit vous pouvez alors compiler le programme.
Comme la méthode standard de création d'exécutables MS Windows est la compilation croisée sous Linux, la méthode recommandée pour développer pour MS Windows est aussi de compiler sous Linux. Cela peut être réalisé soit sur un ordinateur différent à l'aide de ssh, ou sur une machine virtuelle fonctionnant sur le même ordinateur en tant qu'hôte du système MS Windows. Dans les deux cas le répertoire de compilation de Gwyddion (ainsi que les autres répertoire) peuvent être partagés entre les systèmes Linux et MS Windows en utilisant soit Samba soit un moyen de partager les dossiers de la machine virtuelle, les fichiers exécutables peuvent alors être directement testés sous MS Windows sans avoir à transférer des fichiers.