Gwyddion использует систему контроля версий Subversion для управления ревизиями исходного кода. Организация репозитория описана на страницах проекта. Например, последнюю ревизию самой программы можно получить из системы контроля версий командой
svn checkout https://gwyddion.svn.sourceforge.net/svnroot/gwyddion/trunk/gwyddion
Репозиторий не содержит никаких генерируемых файлов, независимо от того, насколько экзотичные инструменты могут понадобиться для их генерации. Следовательно, требуется использование дополнительных пакетов, что накладывает определённые ограничения на выбор определённой платформы. Дополнительные инструменты и пакеты которые нужны для разработки те же. что нужны при сборке из снимка Subversion. Точнее, все инструменты нужны для сборки из свежего снимка, в то время, как разработка может требовать только их подмножество или вообще не требовать, в зависимости от типа и масштаба изменений.
Дополнительные зависимости сборки версии для разработчиков
После загрузки свежего снимка, запустите ./autogen.sh с теми же аргументами, которые вы хотели бы передать configure. Следует отметить. что автоматически добавляется опция --enable-maintainer-mode, которая включает правила make для создания и обновления файлов, которые распространяются внутри архива с исходным кодом (и, следовательно, не генерируются в ходе нормальной компиляции). В общем случае нужно использовать эту опцию configure каждый раз, когда вы собираетесь изменить программу нетривиальным путём.
autogen.sh может закончиться с ошибкой даже если у вас установлены требуемые версии autotools. Некоторые операционные системы не устанавливают общие команды autoconf или automake, а делят их на версии, вроде autoconf261 или automake19. Это делает особенно трудным обнаружить, например «automake 1.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 заканчивается удачно, далее программу можно собирать как обычно. Тем не менее, ещё необходимо создать ряд вещей.
Документация разработчика генерируется командой make docs. Это тоже надо делать явным образом, документация никогда не (пере)создаётся автоматически, опция --enable-gtk-doc команды configure только добавляет цель docs (эта опция включена по умолчанию, следовательно цель docs становится доступна, если в системе обнаруживается gtk-doc).
Файлы MSVC генерируются командой ./utils/update-msvc.py, которую нужно запускать из каталога верхнего уровня с исходным кодом (если интерпретатор Python установлен не в /usr/bin, запускайте командой python ./utils/update-msvc.py). Этот инструмент занимается синхронизацией файлов сборки MSVC и других с файлами Unix, которые берутся за первичный источник. Точнее, update-msvc.py считывает
Makefile.am.libs.deps.gwt, например, makefile.msc.gwtявляется шаблоном для makefile.mscи записывает
.def со списками экспортируемых символов из отдельных библиотек Очевидно, что нужно сначала провести полную сборку проекта (со всеми включенными опциональными возможностями) чтобы правильно сгенерировать эти файлы.
Можно считать update-msvc.py простым специализированным automake, поскольку его основной задачей является генерация файлов make из Makefile.am.
Как можно видеть из предыдущего раздела, прямая сборка из снимка Subversion невозможна под MS Windows, поскольку некоторые из фалов нельзя сгенерировать на этой платформе. Разработка в принципе возможна, хотя определённые изменения,а именно добавление новых фалов и переделки потребуют изменения файлов вручную там, где они автоматически генерируются в системах Unix.
К счастью, доступно большое число свободных unixоподобных систем, например, различные дистрибутивы GNU/Linux. В наиболее неудачном случае можно использовать такую систему для получения файлов, создать все необходимые файлы, сделать архив и перенести его на MS Windows. Это будет эквивалентно использованию ночных снимков репозитория, если не считать того, что архивы можно сгенерировать в любое время.
Тем не менее, также возможно и гораздо более удобно собирать на MS Windows в том же самом каталоге, что и на системе GNU/Linux. Для этого требуется только сделать каталог сборки (обычно в домашнем каталоге) общим с системой Windows используя Samba. Система GNU/Linux может запускаться или на другом физическом компьютере, или в виртуальной машине на том же самом, например внутри VMware player (или наоборот, с MS Windows внутри виртуальной машины, но это не является целью данного раздела).
При сборке под несколько разных операционных систем из одного каталога, некоторое внимание должно уделяться избежанию ошибок, связанных с использованием файлов для другой операционной системы. К счастью, единственными файлами. которые являются общими для систем сборки под Unix и MS Windows являются конфигурационные заголовочные файлы config.h и gwyconfig.h. Чтобы обновить после переключения на MS Windows, просто удалите их, они будут воссозданы в процессе сборки. Чтобы обновить их после переключения на GNU/Linux, запустите ./config.status.