Установка OpenCascade 7.0

/ Просмотров: 1160
"Debug, release... Hey, guys, it seems you have a lot of fun here!" (отрывок из жизни)
В доме праздник: с мест сообщают, что почти готова новая версия OCCT. Эта версия — важная веха в жизни открытого ядра геометрического моделирования Open CASCADE Technology. Поэтому нельзя не уделить внимание его (ядра) установке.

Ранее мы описывали процесс установки OCCT для версий 6.7.x. Подобная информация быстро устаревает, так как с выходом новых версий продукта нередко меняется и процедура его инсталляции. Рекомендуется, конечно, изучить официальную документацию, ведь она, как минимум, всегда актуальна. Однако практика ведения этого блога показала, что вопрос об установке OCCT стоит довольно остро. Поступают даже такие сведения, что кто-то где-то «потратил месяц на установку OpenCascade». Это звучит, признаться, совершенно дико, и отражает скорее состояние бессильной ненависти вопиющего, нежели реальное положение дел. Однако русскоязычному пользователю, особенно новичку, удобнее читать тексты на родном языке. Поэтому приступим.

Начнем с того, что версия 7 — это новый этап в жизни библиотеки. Те, кто знаком с предыдущими версиями, должны помнить такие понятия как CDL и WOK (Workshop Organization Kit). Всего этого больше нет. Отныне конфигурация OCCT осуществляется полностью через CMake. Если раньше CMake-файлы генерировались при помощи специальной утилиты WOK, то теперь они помещены в репозиторий библиотеки, как и подобает хорошему opensource-проекту.

Файлы CMakeLists.txt включены в поставку исходного кода Open CASCADE Technology. На сегодняшний день CMake — рекомендуемый способ сборки библиотеки, хотя и не единственный.

Кроме того, сама процедура конфигурации была изменена и дополнена, что мы прокомментируем ниже отдельно.

Получаем исходные коды библиотеки

Самый хакерский способ — это, конечно, взять исходники напрямую из репозитория:

git clone ssh://gitolite@git.dev.opencascade.org/occt occt

Для этого вам потребуется зарегистрироваться на сайте разработчиков, подписать соглашение об участии в проекте (CLA) и загрузить публичную часть своего SSH-ключа в свой аккаунт. Если сказанное ввергает вас в скепсис (а подписание CLA займет некоторое время), то есть и более простой путь. Достаточно скачать исходные коды библиотеки в виде архива прямо из Git (находим ревизию V7_0_0_beta и кликаем «snapshot») Мы не рассматриваем бинарные поставки OCCT, так как для комфортного владения библиотекой нужно уметь собирать ее вручную (благо, это очень просто).

Скачиваем третьесторонние библиотеки

Open CASCADE Technology — это абсолютно независимая библиотека в части геометрического моделирования. Но в ней содержатся компоненты, использующие некоторые функции сторонних продуктов, прежде всего, для визуализации и интерактивной среды Draw Test Harness (Draw). Для полноценной сборки OCCT, включая командный интерпретатор Draw (как точку входа) требуется Tcl/Tk и Freetype. Остальные зависимости можно безболезненно исключить до тех пор, пока вы не освоитесь с OCCT.

Tcl/Tk эта библиотека является движком для командного интерпретатора Draw. Draw (Draw Test Harness) — это интерактивная среда, из которой вы можете начать работу с библиотекой. Мы уже немного писали о Draw в прошлом.
Freetype работа со шрифтами в Draw. Если планируете использовать Draw, то без этой библиотеки не обойтись.
Freeimage средство, необходимое для юнит-тестирования с использованием Draw. Если тесты вам не нужны, то Freeimage можно исключить из списка зависимостей.
gl2ps поддержка векторных форматов графики (для работы с геометрией она не нужна).
Intel TBB механизм параллелизма. Учитывая, что в OCCT реализован параллелизм при помощи стандартных средств ОС, эту опцию можно игнорировать.
VTK используется для сборки библиотеки IVtk, которая представляет собой «мост» между OCCT и VTK. Используйте, если планируете визуализировать геометрию OCCT при помощи VTK.

Все зависимости подробно описаны на официальном сайте разработчиков. Подробную инструкцию по их сборке можно найти здесь.

OCCT в минимальной сборке не требует вообще никаких зависимостей. В составе библиотеки можно оставить лишь самое необходимое для работы с геометрией и B-Rep, однако для новичков это едва ли хорошее начало. Как и всякий сложный программный продукт, OCCT требует накопления некоторого багажа знаний и опыта, прежде чем жонглирование сборочными параметрами станет для вас делом простым и приятным.

Конфигурируем в CMake

CMake — это утилита, используемая для сборки таких популярных продуктов, как VTK, CGAL, OCCT и другие. Работа с CMake принципиально не отличается в системах Windows и Linux, поэтому все сказанное ниже одинаково справедливо для всех ОС. Работа начинается с запуска CMake GUI (хотя можно использовать и чисто командную версию). Первым делом мы указываем директорию с исходными кодами библиотеки, а также рабочую директорию для сборки. Директория с исходными кодами — это корневая директория OCCT.

Отделение исходных кодов от бинарных путем разнесения их по разным директориям — это хорошо зарекомендовавшая себя практика (не столь, однако, распространенная среди пользователей Windows). В Qt, например, даже принят специальный термин для именования этой техники — «Shadow Build».

Заметим, что рабочая директория (build-директория) по замыслу не окончательна. После того как библиотека будет собрана, ее рекомендуется «инсталлировать», то есть скопировать все заголовочные файлы (*.hxx) и бинарники (*.dll, *.so) туда, где OCCT будет доступна вашему проекту. Вы же собираетесь использовать OCCT не саму по себе, а как часть приложения, верно?

Заметим здесь, что библиотека OCCT, собранная таким образом, не затрагивает глобальных переменных окружения вашей системы. Это важно, так как позволяет иметь несколько версий геометрического ядра для разных платформ и разных проектов.

Build-директория — это своеобразный сборочный цех, в котором начальствует CMake, позволяя экспериментировать с конфигурацией до тех пор, пока состав библиотеки вас не удовлетворит. При этом все прежние настройки сохраняются, то есть не нужно ломать голову над тем, с какими опциями была выполнена сборка некоторое время назад. Под Windows build-директория часто совпадает с директорией, содержащей исходные коды. Так, при сборке проекта Visual Studio по умолчанию создает каталоги Debug или Release там же, где находятся исходники проекта. Хорошо это или плохо зависит от ситуации. Но практика показывает, что при сборке сторонних opensource-продуктов желательно оставлять их исходные директории в первозданном состоянии. Ведь проще готовить сборки под разные платформы, назначая разные build-директории, чем плодить бинарники в одном и том же каталоге.

После выбора рабочей (build) директории мы наблюдаем пустое рабочее поле CMake. Жмем кнопку «Configure» и выбираем «генератор» проектных файлов (MS Visual Studio, Eclipse, Makefiles, etc.).

После первичной конфигурации CMake обнаруживает, что значения некоторых переменных требуют задания. Об этом сигнализирует окошко с ошибкой.

Закрываем его, и первым делом указываем директорию, содержащую третьесторонние продукты, которые вовлечены в сборку.

CMake достаточно умен, чтобы отыскать все сторонние библиотеки автоматически. Но даже если CMake не смог обнаружить все необходимые зависимости автоматически, всегда остается возможность настроить их врукопашную (хотя при правильном порядке действий этого происходить не должно). После очередного нажатия «Configure» мы наблюдаем список переменных конфигурации. Обратите внимание, что все зависимости оказались разрешенными автоматически.

Теперь немного об интересных опциях конфигурирования.

BUILD_ADDITIONAL_TOOLKITS опция для продвинутых пользователей. Здесь вы можете перечислить конкретные библиотеки из состава OCCT, которые следует собрать. Скажем, если топология вам неинтересна, вы можете указать TKGeomAlgo и получить набор библиотек для работы исключительно с параметрической геометрией (без B-Rep). Эта опция CMake достаточно умна, чтобы найти все базовые зависимости и включить их в сборку наравне с отмеченными библиотеками. Так, если вы укажете TKMath, то базовая библиотека TKernel будет добавлена автоматически ввиду того, что TKMath от нее зависит. Библиотеки следует перечислять, разделяя их символом пробела и без расширений (т.е. «.lib» писать не нужно). Кроме того, если вы используете эту опцию, то обратите внимание на переменные BUILD_Module_* — эти флажки (чаще всего) должны быть сняты, иначе в сборке появятся дополнительные библиотеки соответствующих модулей OCCT.
INSTALL_DIR это стандартная, вообще-то, переменная. Обращаем на нее внимание лишь из-за того, что ее важно сразу настроить правильно. Эта переменная указывает, куда будут скопированы бинарники и заголовочные файлы OCCT после инсталляции (make install под Linux или сборка проекта INSTALL в Visual Studio).
INSTALL_TEST_CASES опция полезная для разработчиков библиотеки. Будучи взведенным, этот флажок сигнализирует о том, что тестовые сценарии OCCT (в виде скриптов Tcl) будут скопированы в целевую директорию вместе с бинарниками.

Официальная документация CMake рекомендует нажимать кнопку «Configure» до тех пор, пока в списке не исчезнут подкрашенные красным цветом переменные. На самом деле красный цвет нужен только для того чтобы привлечь ваше внимание. Он сигнализирует о том, что значение переменной было обновлено, т.е. это не сообщение об ошибке, как могло бы показаться.

Создаем проектные файлы и собираем

Нажимаем кнопку «Generate». Происходит создание проектных файлов для нужной нам IDE. Как правило, этот процесс протекает без ошибок, и CMake GUI можно закрыть. Следующий этап — запуск IDE и собственно сборка. Комментировать здесь особо нечего: запускаем среду и собираем проекты. Отметим только, что ваш компилятор должен поддерживать стандарт C++ не ниже версии 11. Для пользователей Windows это означает, что о сборке в таких средах как MS Visual Studio 2008 и ниже можно забыть (OCCT 7 компилируется, начиная с MS Visual Studio 2010).

Для пользователей MS Visual Studio по умолчанию генерируется три конфигурации: Debug, Release и RelWithDebInfo. RelWithDebInfo позволяет компилировать библиотеку в релизе с символами для дебага (это никак не влияет на производительность библиотеки, но может быть полезно для трассировки ошибок). Пользователям Make-файлов режим Debug vs Release придется выбрать на этапе конфигурирования CMake.

По завершении сборки не забываем проинсталлировать библиотеку. Инсталляция — это не более чем копирование бинарников и заголовочных файлов из build-директории в ту, которая была указана в переменной INSTALL_DIR. Данная практика небесполезна: так вы получаете минимально необходимый набор для линковки своего приложения.

В целом, новая версия каскейда старается казаться более современной, избавляясь от шлейфа устаревших компиляторов, и используя более модные практики программирования внутри самой себя. К таким более современным практикам можно причислить умные указатели, полностью переписанные на шаблонах C++, а также обновленный механизм RTTI. Правильный ли это шаг? Безусловно да, если библиотека хочет развиваться. Легко ли переехать со старых версий OCCT на новую? Увы, нет, изменения очень серьезные, и на портирование придется потратить некоторое время.

Запуск

Библиотеку мы уже собрали и проинсталлировали. В прошлый раз мы указали, как легко ее можно проверить на работоспособность. Проделаем примерно то же самое и сейчас. В директории, где установлена OCCT находим скрипт draw.bat (или draw.sh для пользователей Linux).

Запускаем. Появляется консоль и окошко с меню (интерфейс на Tk).

В окошке выбираем «Samples / View Samples ...». Появляется интерфейс для выбора демонстрационных скриптов OCCT. Выбираем какой-нибудь пример, скажем, «OCCT Tutorial bottle shape».

Жмем кнопку «Run sample». Спустя некоторое время на экране появляется фляжка:

Следовательно, все работает. Приятных экспериментов!

Оставьте комментарий!

Имя и сайт используются только при регистрации

Выберите человечка с поднятой рукой!

При нажатии на картинку, Ваш комментарий будет добавлен.