Проблемы, с которыми я столкнулся при компиляции нового 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 и предупреждения уйдут.

C++: члены класса в тени формальных параметров конструктора

Возьмем простую программу

class  A
{
    public:
        explicit A( int  a ) : a( a )
        {}

    private:
        int  a;
};

int  main( void )
{
    A  a( 0 );

    return 0;
}

Что здесь плохо? Видите ли вы потенциальную опасность? Попробуем скомпилировать с включенными предупреждениями:

g++ -Wall -o test test.cc

Всё хорошо. Запуск программы на выполнение также не приводит к каким-либо проблемам (и это неудивительно). А теперь попробуем так:

g++ -Wall -Wshadow -o test test.cc
test.cc: In constructor «A::A(int)»:
test.cc:23:30: предупреждение: декларация «a» перекрывает элемент класса, на который указывает 'this' [-Wshadow]
         explicit A( int  a ) : a( a )
                              ^

Итак, с помощью опции компилятора -Wshadow нам удалось получить интересное предупреждение, которое намекает на то, что если мы будем использовать имя a внутри тела конструктора, то это никоим образом не будет член класса A, но одноименный формальный параметр, переданный в конструктор. Вот так то! Всё бы ничего, мы ведь сами не дураки и знаем, что если нам понадобится член класса, то мы сможем обратиться к нему через указатель this.

Казалось бы, в чем проблема, просто не использовать -Wshadow и дело с концом. А теперь представьте, что ваш код, написанный в таком стиле, когда имя формального параметра совпадает с именем члена класса, инициализируемого этим параметром, является частью большого проекта, при сборке которого было решено добавить -Wshadow, и вы не можете убрать эту опцию при сборке вашей части (такое вполне возможно, если система построения проекта хорошо автоматизирована и вы можете изменять на своей стороне лишь часть деклараций)! Компиляция вашего участка превратится в настоящий кошмар с выводом на экран огромного количества предупреждений, подобных приведенному выше (особенно если вы предпочитаете помещать реализации конструкторов внутри заголовочных файлов).

Как же с этим бороться? Самый очевидный способ - рефакторинг. Имена формальных параметров конструкторов и членов класса должны отличаться. Например, именем формального параметра в приведенном примере остается a, а имя члена класса переименовываем в a_. Лично мне такой стиль совершенно не импонирует. В самом деле, инициализацию членов класса через формальные параметры конструктора хотелось бы рассматривать как чисто языковой элемент, не вдаваясь в подробности реализации, такие как копирование одного объекта в другой. Иначе страдает абстракция и такой, казалось бы, простой шаблон, как инициализация членов класса формальными параметрами конструктора, начинает обрастать ненужными деталями.

Второй способ - обрамление объявлений конструкторов прагмами компилятора, отключающими диагностические сообщения. Например, в случае gcc конструктор A из приведенного выше примера может быть записан так:

#pragma GCC diagnostic ignored "-Wshadow"
        explicit A( int  a ) : a( a )
        {}
#pragma GCC diagnostic pop

Минусы здесь очевидны. Во-первых, мы так и не добились желаемого уровня абстракции шаблона инициализации членов класса, засорив его еще менее понятными объявлениями. Во-вторых, прагмы, как известно, не переносимы, и для разных компиляторов они будут отличаться. В-третьих, если проект достаточно большой, то вставка большого количества прагм замусорит код.

В общем, как правильно решить такую проблему мне пока не ясно. Очень хочется сохранить простой шаблон инициализации членов класса формальными параметрами конструктора, в котором оба языковых элемента (то есть члены класса и формальные параметры конструктора) рассматриваются абстрактно и имеют одно имя. Однако C++, к сожалению, не является настолько выразительным, чтобы это можно было сделать безопасно, и включение опции -Wshadow напоминает нам об этом. Увы, по всей видимости, использование разных имен для членов класса и формальных параметров конструктора - это единственный полностью безопасный подход.