Проблемы, с которыми я столкнулся при компиляции нового Geant4 10.0

Новая версия замечательной библиотеки Geant4 вышла 6 декабря. Я решил написать данную статью, так как встретился с одним интересным багом, который не давал скомпилировать новый Geant4. Баг связан не с самой библиотекой Geant4, и даже не с cmake, а с компилятором moc из Qt4.

Итак, последние версии Geant4 компилируются исключительно с помощью cmake. Для этого создается новая директория, например geant4.10.00-build/, и в ней запускается cmake. Я обычно использую псевдографическую оболочку ccmake (см. здесь) или обычный консольный cmake в интерактивном режиме (с опцией -i) - это позволяет включить различные опции, выключенные по умолчанию. Так, для своих нужд я обычно включаю опции GEANT4_USE_GDML, GEANT4_USE_OPENGL_X11 и GEANT4_USE_QT. Кроме того, в версии Geant4 10.0 появилась возможность включить многопоточную обработку событий при компиляции библиотеки с опцией GEANT4_BUILD_MULTITHREADED: ее включение позволит протестировать эту новую киллер-фичу.

По завершении конфигурирования билда cmake запускаем обычный make. Ждем окончания компиляции, если повезет... Мне не повезло. Когда статус достиг 84%, она прервалась с таким сообщением об ошибке:

[ 84%] Generating basic/include/moc_G4UIQt.cxx
moc: Cannot open options file specified with @
Usage: moc [options] <header-file>
  -o<file>           write output to file rather than stdout
  -I<dir>            add dir to the include path for header files
  -E                 preprocess only; do not generate meta object code
  -D<macro>[=<def>]  define macro, with optional definition
  -U<macro>          undefine macro
  -i                 do not generate an #include statement
  -p<path>           path prefix for included file
  -f[<file>]         force #include, optional file name
  -nn                do not display notes
  -nw                do not display warnings
  @<file>            read additional options from file
  -v                 display version of moc
make[2]: *** [source/interfaces/basic/include/moc_G4UIQt.cxx] Ошибка 1
make[1]: *** [source/interfaces/CMakeFiles/G4interfaces.dir/all] Ошибка 2
make: *** [all] Ошибка 2

Это и есть тот самый интересный баг, который я анонсировал в начале статьи. Для его воспроизведения требуется стечение нескольких обстоятельств: Geant4 должен компилироваться с поддержкой Qt, мажорная версия Qt не должна быть выше 4 (на моей Fedora 19 установлена Qt4 8.5) и в полном пути к директории, из которой выполняется cmake, должны присутствовать нелатинские символы (у меня эта директория находилась в $HOME/Загрузки/). Выяснилось, что во всем виноват компилятор moc, который ошибочно обрабатывает опцию @<file>, если в ней присутствуют нелатинские символы. В этом багрепорте описана проблема. Оказалось, что она уже решена в Qt5 и, поскольку ее проявления должны быть весьма редкими, то чинить ее в Qt4 нет смысла. Что же делать, если вас постигла такая неудача? Да просто строить билд Geant4 в директории, в пути к которой нет нелатинских символов!

После успешного завершения компиляции выполняем make install, переходим в директорию, куда были установлены данные (она задается переменной cmake GEANT4_INSTALL_DATADIR), и проверяем все ли они на месте: у меня почему-то не оказалось данных в поддиректориях G4PII1.3, G4SAIDDATA1.1 и RealSurface1.0, и из-за этого уже скомпилированное и запущенное приложение упало при запуске первого же события. В случае отсутствия данных в поддиректориях скачиваем их отсюда (из раздела Data Files) и устанавливаем вручную.

Теперь о настройках среды. Я уже рассказывал об этом здесь. Но, поскольку в новой версии Geant4 использование простого Makefile больше не поддерживается, то и сорсинг geant4make.sh больше не нужен. Соответственно, в $HOME/.bash_profile теперь помещаем такие строки:

export G4ROOT=/usr/local/geant4
export G4CONFIGDIR=$G4ROOT/lib64/Geant4-10.0.0
export G4WORKDIR=$HOME/geant4

[ -f $G4ROOT/bin/geant4.sh ] && . $G4ROOT/bin/geant4.sh

PATH=$PATH:$G4WORKDIR/bin

Для компиляции приложений, которые используют Geant4, нужно использовать cmake. Создаем отдельную директорию, переходим в нее и конфигурируем билд:

cmake -DCMAKE_INSTALL_PREFIX:PATH=$G4WORKDIR -DGeant4_DIR=$G4CONFIGDIR <path-to-srcs>

Здесь <path-to-srcs> - это директория с исходниками приложения. В принципе, билд можно сконфигурировать прямо внутри этой директории и аргумент cmake <path-to-src> в этом случае не нужен, однако это замусорит директорию с исходниками, поэтому такой подход обычно не рекомендуют. После успешной конфигурации запускаем make и, если нужно, make install.

Еще одна проблема, с которой я столкнулся при компиляции своего приложения - это огромное количество предупреждений о перекрытии (shadowing) имен. Дело в том, что в новой версии Geant4 в скрипты cmake была добавлена опция компилятора -Wshadow, которая выдает предупреждения, если, например, имена формальных параметров конструкторов класса и их членов совпадают. Я писал об этом здесь. Проблема в том, что такой уж у меня стиль: я всегда именую формальные параметры конструкторов и члены класса, которые они инициализируют, одинаково. Такой подход полностью противоречит модели, в которой перекрытия имен не дозволяются. Как быть? Ведь я не собираюсь переименовывать огромное количество членов всевозможных классов в своем проекте только для того, чтобы убрать эти предупреждения. Оказывается, их легко подавить, если вставить в файл CMakeLists.txt строку

add_definitions(-Wno-shadow)

где-нибудь внизу после включения ${Geant4_USE_FILE}. В этом случае противоположная опции -Wshadow опция -Wno-shadow победит исходно установленную -Wshadow и предупреждения уйдут.

Чиним f-spot

Я использую f-spot в качестве менеджера коллекций фотографий на своем домашнем компьютере. К сожалению, начиная с версии 0.8.0 f-spot испортился: тамбнейлы превратились в серые квадратики, а при клике на них фотографии открывались на долю секунды и f-spot тут же падал. Поиск в интернете вывел на баг #627745. В двух словах баг заключается в том, что если в пути к файлам с фотографиями встречаются директории с нелатинскими символами, то f-spot благополучно падает. В пути к моим фото присутствует директория Снимки/, так что мне не повезло.
Некоторое время я терпеливо ждал выхода следующей версии f-spot. Но, f-spot 0.8.2 вышел, а проблема осталась. Пришла пора действовать. Итак, для восстановления работоспособности f-spot была применена стратегия, состоящая из двух основных пунктов:

1. Сделать так, чтобы путь к файлам с фотографиями не содержал нелатинских символов
2. Сделать так, чтобы f-spot узнал об изменениях в пункте 1

Первый пункт достигается очень просто: нужно использовать старые добрые символические ссылки:

ln -s Снимки Pictures

Теперь к фотографиям можно обращаться через путь Pictures/ вместо Снимки/.
Чтобы реализовать второй пункт, нужно знать как f-spot хранит информацию о фотографиях. А делает он это с помощью базы данных photos.db, которая обычно находится в директории ~/.config/f-spot/. Редактировать эту БД можно с помощью утилиты sqlite3. Естественно, перед тем как изменять БД, неплохо создать ее резервную копию, просто скопировав файл photos.db. Итак, открываем БД для внесения нужных изменений:

sqlite3 photos.db

Эта команда загружает интерактивную среду sqlite. Для просмотра перечня таблиц вводим

sqlite> .tables
exports         meta            photo_versions  rolls         
jobs            photo_tags      photos          tags

Поля отдельной таблицы можно увидеть с помощью команды .schema:

sqlite> .schema photos
CREATE TABLE photos (
    id          INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, 
    time            INTEGER NOT NULL, 
    base_uri        STRING NOT NULL, 
    filename        STRING NOT NULL, 
    description     TEXT NOT NULL, 
    roll_id         INTEGER NOT NULL, 
    default_version_id  INTEGER NOT NULL, 
    rating          INTEGER NULL 
);

Увидеть, где находятся данные, содержащие пути с директорией Снимки/ было просто: достаточно выполнить select * from для всех (или только подозрительных) таблиц. Оказалось, что данные о путях содержатся в полях base_uri таблиц photos и photo_versions.
Теперь нужно выполнить замену Снимки на Pictures во всех данных для этих полей:

sqlite> update photos set base_uri=replace(base_uri,"Снимки","Pictures")
   ...> where base_uri like "%Снимки%";
sqlite> update photo_versions set base_uri=replace(base_uri,"Снимки","Pictures")
   ...> where base_uri like "%Снимки%";

Всё. Выходим из среды sqlite:

sqlite> .quit

Теперь запускаем f-spot: тамбнейлы должны появиться, при клике на них фотографии должны показываться без проблем. Осталось изменить имя директории, в которую будут импортироваться фото в дальнейшем c Снимки на Pictures: это можно сделать прямо в f-spot из меню Правка -> Параметры.

P.S. Похоже, что этот баг не связан напрямую с f-spot, возможно он присутствует на уровне mono или Gnome.

P.P.S. Я пробовал использовать shotwell, но f-spot мне по-прежнему кажется симпатичней, несмотря на свою глючность. Возможно, в дальнейшем я перейду на shotwell, когда его допилят.