Gwyddion использует систему контроля версий Subversion для управления ревизиями исходного кода. Организация репозитория описана на страницах проекта. Например, последнюю ревизию самой программы можно получить из системы контроля версий командой
svn checkout http://svn.code.sf.net/p/gwyddion/code/trunk/gwyddion
Репозиторий не содержит никаких генерируемых файлов, независимо от того, насколько экзотичные инструменты могут понадобиться для их генерации. Следовательно, требуется использование дополнительных пакетов, для сборки свежего снимка. Также существуют определённые ограничения платформы. Дополнительные инструменты и пакеты которые нужны для разработки те же, что нужны при сборке из снимка Subversion. Точнее, все инструменты нужны для сборки из свежего снимка, в то время, как разработка может требовать только их подмножество или вообще не требовать, в зависимости от типа и масштаба изменений исходного кода.
Дополнительные зависимости для сборки версии для разработчиков
После загрузки свежего снимка, запустите ./autogen.sh с теми же аргументами, которые вы хотели бы передать configure. Следует отметить. что автоматически добавляются опции --enable-maintainer-mode и --enable-gtk-doc, чтобы убедиться, чт оправила создания и обновления различных файлов будут активны. В общем случае нужно использовать эту опцию configure каждый раз, когда вы собираетесь изменить исходный код программы нетривиальным путём.
На некоторых системах autogen.sh может закончиться с ошибкой даже если у вас установлены требуемые версии autotools. Эти системы не устанавливают общие команды autoconf или automake, а делят их на версии, вроде autoconf261 или automake19. Найти, например, «automake1.9 или новее» без знания насколько новым он может быть будет весьма нетривиальной задачей. Следовательно, autogen.sh даже не пытается этого сделать. Можно или создать не содержащие версий символические ссылки на команды с версиями или запустить autogen.sh следующим образом:
AUTOCONF=autoconf261 AUTOHEADER=autoheader261 ./autogen.sh Может потребоваться установка следующих переменных: ACLOCAL, AUTOCONF, AUTOHEADER, AUTOM4TE, AUTOMAKE, LIBTOOLIZE. Дополнительно, некоторые операционные системы могут установить макрос autoconf в такое место, где aclocal по умолчанию их не найдёт. Это может быть исправлено установкой переменной ACLOCAL_FLAGS, где будут указаны дополнительные пути поиска для aclocal:
ACLOCAL_FLAGS="-I /usr/local/share/aclocal" ./autogen.sh Нередко требуется комбинировать эти настройки. Например, на FreeBSD, где все инструменты разделены по версиям, обычно требуется выполнить (разбито на строки для простоты чтения):
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=...
Если autogen.sh заканчивается удачно, далее программу можно собирать как обычно.
Поскольку стандартный метод создания исполняемых файлов MS Windows состоит в кросс-компиляции в Linux, рекомендуемый способ разработки для MS Windows также состоит в сборке под Linux. Это можно делать как на физически другом компьютере используя ssh, так и на виртуальной машине запущенной на том же компьютере, что и основная система MS Windows. В обоих случаях каталоги сборки Gwyddion (и другие каталоги) могут быть общими для Linux и MS Windows используя либо Samba, либо механизм общих каталогов виртуальной машины. Собранные таким образом исполняемые файлы можно сразу тестировать в MS Windows не перенося их туда и обратно.