Компиляция Manticore из исходников

Компиляция Manticore Search из исходных кодов позволяет создавать пользовательские конфигурации сборки, такие как отключение определённых функций или добавление новых патчей для тестирования. Например, вы можете захотеть скомпилировать из исходников и отключить встроенный ICU, чтобы использовать другую версию, установленную в вашей системе, которую можно обновлять независимо от Manticore. Это также полезно, если вы хотите внести вклад в проект Manticore Search.

Сборка с использованием CI Docker

Для подготовки официальных релизных и девелоперских пакетов мы используем Docker и специальный образ для сборки. Этот образ включает необходимые инструменты и предназначен для использования с внешними sysroots, так что один контейнер может собирать пакеты для всех операционных систем. Вы можете собрать образ, используя Dockerfile и README или использовать образ с Docker Hub. Это самый простой способ создать бинарные файлы для любой поддерживаемой операционной системы и архитектуры. Также вам нужно будет указать следующие переменные окружения при запуске контейнера:

Чтобы узнать возможные значения для DISTR и arch, вы можете использовать каталог https://repo.manticoresearch.com/repository/sysroots/roots_with_zstd/ в качестве справочника, так как он содержит sysroots для всех поддерживаемых комбинаций.

После этого сборка пакетов внутри Docker-контейнера так же проста, как вызов:

cmake -DPACK=1 /path/to/sources
cmake --build .

Например, чтобы создать пакет для Ubuntu Jammy, аналогичный официальной версии, предоставляемой командой Manticore Core, выполните следующие команды в каталоге с исходниками Manticore Search. Этот каталог является корнем клонированного репозитория с https://github.com/manticoresoftware/manticoresearch:

docker run -it --rm \
-e CACHEB="../cache" \
-e DIAGNOSTIC=1 \
-e PACK_ICUDATA=0 \
-e NO_TESTS=1 \
-e DISTR=jammy \
-e boost=boost_nov22 \
-e sysroot=roots_nov22 \
-e arch=x86_64 \
-e CTEST_CMAKE_GENERATOR=Ninja \
-e CTEST_CONFIGURATION_TYPE=RelWithDebInfo \
-e WITH_COVERAGE=0 \
-e SYSROOT_URL="https://repo.manticoresearch.com/repository/sysroots" \
-e HOMEBREW_PREFIX="" \
-e PACK_GALERA=0 \
-e UNITY_BUILD=1 \
-v $(pwd):/manticore_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \
manticoresearch/external_toolchain:vcpkg331_20250114 bash
# following is to be run inside docker shell
cd /manticore_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/
mkdir build && cd build
cmake -DPACK=1 ..
export CMAKE_TOOLCHAIN_FILE=$(pwd)/dist/build_dockers/cross/linux.cmake
cmake --build .
# or if you want to build packages:
# cmake --build . --target package

Требуется длинный путь к каталогу исходников, иначе сборка может не пройти в некоторых случаях (например, Centos).

Аналогично, вы можете собирать бинарные файлы или пакеты не только для популярных дистрибутивов Linux, но и для FreeBSD, Windows и macOS.

Сборка SRPM с использованием Docker

Вы также можете использовать тот же специальный образ Docker для сборки SRPM:

docker run -it --rm \
-e CACHEB="../cache" \
-e DIAGNOSTIC=1 \
-e PACK_ICUDATA=0 \
-e NO_TESTS=1 \
-e DISTR=rhel8 \
-e boost=boost_rhel_feb17 \
-e sysroot=roots_nov22 \
-e arch=x86_64 \
-e CTEST_CMAKE_GENERATOR=Ninja \
-e CTEST_CONFIGURATION_TYPE=RelWithDebInfo \
-e WITH_COVERAGE=0 \
-e SYSROOT_URL="https://repo.manticoresearch.com/repository/sysroots" \
-e HOMEBREW_PREFIX="" \
-e PACK_GALERA=0 \
-e UNITY_BUILD=1 \
-v $(pwd):/manticore_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \
manticoresearch/external_toolchain:vcpkg331_20250114 bash
# following is to be run inside docker shell
cd /manticore_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/
mkdir build && cd build
cmake -DPACK=1 ..
export CMAKE_TOOLCHAIN_FILE=$(pwd)/../dist/build_dockers/cross/linux.cmake
# The CPackSourceConfig.cmake file is now generated in the build directory
cpack -G RPM --config ./CPackSourceConfig.cmake

Это создаст Source RPM (.src.rpm файл), содержащий весь исходный код.

Сборка бинарных RPM из SRPM

После создания SRPM вы можете использовать его для сборки полного набора бинарных RPM пакетов:

# Install build tools and dependencies
dnf install -y rpm-build cmake gcc-c++ boost-devel epel-release
# Install SRPM dependencies automatically
dnf builddep -y manticore-*.src.rpm
# Build all binary RPMs from the SRPM
rpmbuild --rebuild manticore-*.src.rpm
# Find the generated packages
ls ~/rpmbuild/RPMS/*/manticore*

ПРИМЕЧАНИЕ: Для сборки RPM из SRPM необходимо убедиться, что все зависимости, указанные в SRPM, полностью установлены, что может быть сложно. SRPM всё равно может быть полезен для:

  • Аудита процесса сборки или изучения исходников и spec-файлов
  • Внесения пользовательских изменений или патчей в сборку
  • Понимания, как были созданы бинарные файлы
  • Соблюдения требований лицензий с открытым исходным кодом

Ручная сборка

Компиляция Manticore без использования Docker для сборки не рекомендуется, но если вам нужно это сделать, вот что может быть полезно знать:

Необходимые инструменты

  • Компилятор C++
    • В Linux - можно использовать GNU (4.7.2 и выше) или Clang
    • В Windows - Microsoft Visual Studio 2019 и выше (достаточно community edition)
    • На macOS - Clang (из командных инструментов XCode, используйте xcode-select --install для установки).
  • Bison, Flex - на большинстве систем доступны как пакеты, в Windows доступны в среде cygwin.
  • Cmake - используется на всех платформах (требуется версия 3.19 или выше)

Получение исходников

Из git

Исходный код Manticore размещён на GitHub. Чтобы получить исходный код, клонируйте репозиторий и затем переключитесь на нужную ветку или тег. Ветка master представляет основную ветку разработки. При выпуске создаётся тег с версией, например 3.6.0, и начинается новая ветка для текущего релиза, в данном случае manticore-3.6.0. Голова версии ветки после всех изменений используется как источник для сборки всех бинарных релизов. Например, чтобы взять исходники версии 3.6.0, выполните:

git clone https://github.com/manticoresoftware/manticoresearch.git
cd manticoresearch
git checkout manticore-3.6.0

Из архива

Вы можете скачать нужный код с GitHub, используя кнопку "Download ZIP". Подходят форматы .zip и .tar.gz.

wget -c https://github.com/manticoresoftware/manticoresearch/archive/refs/tags/3.6.0.tar.gz
tar -zxf 3.6.0.tar.gz
cd manticoresearch-3.6.0

Конфигурация

Manticore использует CMake. Предположим, вы находитесь в корневом каталоге клонированного репозитория:

mkdir build && cd build
cmake ..

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

Вы также можете явно настроить сборку с помощью флагов и опций. Чтобы включить функцию FOO, добавьте -DFOO=1 к вызову CMake. Чтобы отключить, используйте -DFOO=0. Если явно не указано иное, включение функции, которая недоступна((например, WITH_GALERA в сборке для MS Windows)) приведет к ошибке конфигурации. Отключение функции, помимо исключения её из сборки, также отключает её проверку в системе и загрузку/сборку любых связанных внешних библиотек.

Флаги и опции конфигурации

  • USE_SYSLOG - позволяет использовать syslog в логировании запросов.
  • WITH_GALERA - Включает поддержку репликации в поисковом демоне. Поддержка будет настроена для сборки, а исходники библиотеки Galera будут загружены, собраны и включены в дистрибутив/установку. Обычно безопасно собирать с Galera, но не распространять саму библиотеку (то есть без модуля Galera, без репликации). Однако иногда может потребоваться явно отключить её, например, если вы хотите собрать статический бинарный файл, который по конструкции не может загружать библиотеки, так что даже наличие вызова функции 'dlopen' внутри демона вызовет ошибку линковки.
  • WITH_RE2 - Сборка с использованием библиотеки регулярных выражений RE2. Это необходимо для функций, таких как REGEX(), и функции regexp_filter.
  • WITH_RE2_FORCE_STATIC - Загружает исходники RE2, компилирует их и статически линкует, так что итоговые бинарники не будут зависеть от наличия общей библиотеки RE2 в вашей системе.
  • WITH_STEMMER - Сборка с использованием библиотеки стемминга Snowball.
  • WITH_STEMMER_FORCE_STATIC - Загружает исходники Snowball, компилирует их и статически линкует, так что итоговые бинарники не будут зависеть от наличия общей библиотеки libstemmer в вашей системе.
  • WITH_ICU - Сборка с библиотекой ICU (International Components for Unicode). Используется для сегментации китайского текста. Применяется при использовании morphology=icu_chinese.
  • WITH_JIEBA - Сборка с инструментом сегментации китайского текста Jieba. Используется для сегментации китайского текста. Применяется при использовании morphology=jieba_chinese.
  • WITH_ICU_FORCE_STATIC - Загружает исходники ICU, компилирует их и статически линкует, так что итоговые бинарники не будут зависеть от наличия общей библиотеки icu в вашей системе. Также включает файл данных ICU в установку/дистрибутив. Цель статической линковки ICU — иметь библиотеку известной версии, чтобы поведение было определённым и не зависело от системных библиотек. Скорее всего, вы предпочтёте использовать системную ICU, так как она может обновляться без необходимости перекомпиляции демона Manticore. В этом случае нужно явно отключить эту опцию. Это также сэкономит место, занимаемое файлом данных ICU (около 30М), так как он не будет включён в дистрибутив.
  • WITH_SSL - Используется для поддержки HTTPS, а также зашифрованных MySQL-соединений с демоном. Системная библиотека OpenSSL будет связана с демоном. Это означает, что для запуска демона потребуется OpenSSL. Это обязательно для поддержки HTTPS, но не строго обязательно для сервера (то есть отсутствие SSL означает невозможность подключения по HTTPS, но другие протоколы будут работать). Manticore может использовать версии SSL-библиотеки от 1.0.2 до 1.1.1, однако в целях безопасности настоятельно рекомендуется использовать максимально свежую версию SSL-библиотеки. На данный момент поддерживается только версия 1.1.1, остальные устарели (см. стратегию релизов openssl).
  • WITH_ZLIB - используется индексатором для работы с сжатыми колонками из MySQL. Используется демоном для поддержки сжатого протокола MySQL.
  • WITH_ODBC - используется индексатором для поддержки индексации источников из ODBC-провайдеров (обычно UnixODBC и iODBC). В MS Windows ODBC — правильный способ работы с источниками MS SQL, поэтому индексация MSSQL также подразумевает этот флаг.
  • DL_ODBC - не линкуется с библиотекой ODBC. Если ODBC линкуется, но недоступна, вы не сможете запустить инструмент indexer, даже если хотите обработать что-то, не связанное с ODBC. Эта опция заставляет индексатор загружать библиотеку во время выполнения только при работе с источником ODBC.
  • ODBC_LIB - имя файла библиотеки ODBC. Индексатор попытается загрузить этот файл при работе с источником ODBC. Эта опция автоматически устанавливается на основе обнаружения доступной общей библиотеки ODBC. Вы также можете переопределить это имя во время выполнения, задав переменную окружения ODBC_LIB с правильным путём к альтернативной библиотеке перед запуском индексатора.
  • WITH_EXPAT - используется индексатором для поддержки индексации источников xmlpipe.
  • DL_EXPAT - не линкуется с библиотекой EXPAT. Если EXPAT линкуется, но недоступна, вы не сможете запустить инструмент indexer, даже если хотите обработать что-то, не связанное с xmlpipe. Эта опция заставляет индексатор загружать библиотеку во время выполнения только при работе с источником xmlpipe.
  • EXPAT_LIB - имя файла библиотеки EXPAT. Индексатор попытается загрузить этот файл при работе с источником xmlpipe. Эта опция автоматически устанавливается на основе обнаружения доступной общей библиотеки EXPAT. Вы также можете переопределить это имя во время выполнения, задав переменную окружения EXPAT_LIB с правильным путём к альтернативной библиотеке перед запуском индексатора.
  • WITH_ICONV - для поддержки различных кодировок при индексации источников xmlpipe с помощью индексатора.
  • DL_ICONV - не линкуется с библиотекой iconv. Если iconv линкуется, но недоступна, вы не сможете запустить инструмент indexer, даже если хотите обработать что-то, не связанное с xmlpipe. Эта опция заставляет индексатор загружать библиотеку во время выполнения только при работе с источником xmlpipe.
  • ICONV_LIB - имя файла библиотеки iconv. Индексатор попытается загрузить этот файл, когда вы захотите обработать источник xmlpipe. Эта опция записывается автоматически на основе доступных исследованных разделяемых библиотек iconv. Вы также можете переопределить это имя во время выполнения, задав переменную окружения ICONV_LIB с правильным путем к альтернативной библиотеке перед запуском индексатора.
  • WITH_MYSQL - используется индексатором для поддержки индексирования источников MySQL.
  • DL_MYSQL - не связывать с библиотекой MySQL. Если MySQL связана, но недоступна, вы не сможете запустить инструмент indexer, даже если хотите обработать что-то, не связанное с MySQL. Эта опция заставляет индексатор загружать библиотеку во время выполнения только тогда, когда вы хотите работать с источником MySQL.
  • MYSQL_LIB -- имя файла библиотеки MySQL. Индексатор попытается загрузить этот файл, когда вы захотите обработать источник MySQL. Эта опция записывается автоматически на основе доступных исследованных разделяемых библиотек MySQL. Вы также можете переопределить это имя во время выполнения, задав переменную окружения MYSQL_LIB с правильным путем к альтернативной библиотеке перед запуском индексатора.
  • WITH_POSTGRESQL - используется индексатором для поддержки индексирования источников PostgreSQL.
  • DL_POSTGRESQL - не связывать с библиотекой PostgreSQL. Если PostgreSQL связана, но недоступна, вы не сможете запустить инструмент indexer, даже если хотите обработать что-то, не связанное с PostgreSQL. Эта опция заставляет индексатор загружать библиотеку во время выполнения только тогда, когда вы хотите работать с источником PostgreSQL.
  • POSTGRESQL_LIB - имя файла библиотеки postgresql. Индексатор попытается загрузить указанный файл библиотеки postgresql при обработке источника postgresql. Эта опция автоматически определяется на основе доступных исследованных разделяемых библиотек postgresql. Вы также можете переопределить имя во время выполнения, задав переменную окружения POSTGRESQL_LIB с правильным путем к альтернативной библиотеке перед запуском индексатора.
  • LOCALDATADIR - путь по умолчанию, где демон хранит binlogs. Если этот путь не указан или явно отключен в конфигурации времени выполнения демона (т.е. в файле manticore.conf, который не связан с этой конфигурацией сборки), binlogs будут размещены в этом пути. Обычно это абсолютный путь, однако он не обязательно должен быть таковым, можно использовать и относительные пути. Вероятно, вам не нужно менять значение по умолчанию, определённое конфигурацией, которое, в зависимости от целевой системы, может быть таким, как /var/data, /var/lib/manticore/data или /usr/local/var/lib/manticore/data.
  • FULL_SHARE_DIR - путь по умолчанию, где хранятся все ресурсы. Его можно переопределить переменной окружения FULL_SHARE_DIR перед запуском любого инструмента, который использует файлы из этой папки. Это важный путь, так как многие вещи по умолчанию ожидаются именно там. Сюда входят предопределённые таблицы символов, стоп-слова, модули manticore и файлы данных icu, все размещённые в этой папке. Скрипт конфигурации обычно определяет этот путь как что-то вроде /usr/share/manticore или /usr/local/share/manticore.
  • DISTR_BUILD - ярлык для опций выпуска пакетов. Это строковое значение с именем целевой платформы. Его можно использовать вместо ручной настройки всех опций. В Debian и Redhat Linux значение по умолчанию может определяться лёгкой интроспекцией и устанавливаться как общее 'Debian' или 'RHEL'. В противном случае значение не определено.
  • PACK - ещё более удобный ярлык. Он читает переменную окружения DISTR, присваивает её параметру DISTR_BUILD, а затем работает как обычно. Это очень полезно при сборке в подготовленных системах сборки, таких как контейнеры Docker, где переменная DISTR установлена на уровне системы и отражает целевую систему, для которой предназначен контейнер.
  • CMAKE_INSTALL_PREFIX (путь) - где ожидается установка Manticore. Сборка не выполняет установку, но подготавливает правила установки, которые выполняются при запуске команды cmake --install или создании пакета с последующей установкой. Префикс можно изменить в любое время, даже во время установки, вызвав cmake --install . --prefix /path/to/installation. Однако во время конфигурации эта переменная используется для инициализации значений по умолчанию для LOCALDATADIR и FULL_SHARE_DIR. Например, установка её в /my/custom во время конфигурации зафиксирует LOCALDATADIR как /my/custom/var/lib/manticore/data, а FULL_SHARE_DIR как /my/custom/usr/share/manticore.
  • BUILD_TESTING (bool) поддержка тестирования. Если включено, после сборки вы можете запустить 'ctest' и протестировать сборку. Обратите внимание, что тестирование подразумевает дополнительные зависимости, такие как наличие PHP cli, Python и доступного сервера MySQL с тестовой базой данных. По умолчанию этот параметр включён. Поэтому для «просто сборки» вы, возможно, захотите отключить опцию, явно указав значение 'off'.
  • BUILD_SRPMS (bool) показывать инструкции по сборке исходных RPM-пакетов (SRPM). Из-за ограничений CPack с упаковкой на основе компонентов, SRPM не могут быть сгенерированы напрямую вместе с бинарными RPM. При включении система сборки покажет инструкции для правильной генерации SRPM с использованием метода конфигурации исходников. По умолчанию этот параметр выключен.
  • LIBS_BUNDLE - путь к папке с различными библиотеками. Это в основном актуально для сборки под Windows, но может быть полезно, если вам часто приходится собирать, чтобы избежать загрузки сторонних исходников каждый раз. По умолчанию этот путь не изменяется скриптом конфигурации; вы должны положить всё туда вручную. Например, если нужна поддержка стеммера — исходники будут загружены с домашней страницы Snowball, затем распакованы, сконфигурированы, собраны и т.д. Вместо этого вы можете хранить оригинальный архив исходников (который называется libstemmer_c.tgz) в этой папке. В следующий раз при сборке с нуля скрипт конфигурации сначала проверит наличие стеммера в бандле, и если он там есть, не будет загружать его снова из Интернета.
  • CACHEB - путь к папке с сохранёнными сборками сторонних библиотек. Обычно такие функции, как galera, re2, icu и т.д., сначала скачиваются или берутся из бандла, затем распаковываются, собираются и устанавливаются во временную внутреннюю папку. При сборке manticore эта папка затем используется как место, где находятся необходимые для поддержки запрашиваемой функции компоненты. В итоге они либо линкуются с manticore, если это библиотека; либо идут напрямую в дистрибутив/установку (например, galera или данные icu). Когда CACHEB определён либо как параметр конфигурации cmake, либо как системная переменная окружения, он используется как целевая папка для этих сборок. Эта папка может сохраняться между сборками, чтобы сохранённые там библиотеки больше не пересобирались, что значительно сокращает весь процесс сборки. Обратите внимание, что некоторые опции организованы тройками: WITH_XXX, DL_XXX и XXX_LIB — например, поддержка mysql, odbc и т.д. WITH_XXX определяет, будут ли влиять следующие две. То есть, если вы установите WITH_ODBC в 0, нет смысла задавать DL_ODBC и ODBC_LIB, и эти две опции не будут иметь эффекта, если вся функция отключена. Также XXX_LIB не имеет смысла без DL_XXX, потому что если вы не хотите использовать опцию DL_XXX, динамическая загрузка не будет использоваться, и имя, заданное в XXX_LIB, бесполезно. Это используется по умолчанию для интроспекции. Также использование библиотеки iconv предполагает наличие expat и бесполезно, если последний отключён. Кроме того, некоторые библиотеки могут быть всегда доступны, и поэтому нет смысла избегать их линковки. Например, в Windows это ODBC. На macOS это Expat, iconv и, возможно, другие. По умолчанию интроспекция определяет такие библиотеки и фактически генерирует только WITH_XXX для них, без DL_XXX и XXX_LIB, что упрощает ситуацию.

С некоторыми опциями конфигурация может выглядеть так:

mkdir build && cd build

cmake -DWITH_MYSQL=1 -DWITH_RE2=1 ..

Помимо общих значений конфигурации, вы также можете изучить файл CMakeCache.txt, который остаётся в папке сборки сразу после запуска конфигурации. Любые значения, определённые там, могут быть переопределены явно при запуске cmake. Например, вы можете запустить cmake -DHAVE_GETADDRINFO_A=FALSE ..., и этот запуск конфигурации не будет учитывать исследуемое значение этой переменной, а будет использовать то, которое вы указали.

#### Специфические переменные окружения
Переменные окружения полезны для предоставления некоторого рода глобальных настроек, которые хранятся отдельно от конфигурации сборки и всегда присутствуют. Для постоянства их можно задать глобально в системе разными способами — например, добавив их в файл `.bashrc`, или встроив в Dockerfile, если вы создаёте систему сборки на основе Docker, или записав их в системные переменные окружения в настройках Windows. Также их можно задать временно с помощью `export VAR=value` в оболочке. Или ещё короче — предваряя вызов cmake значениями, например `CACHEB=/my/cache cmake ...` — так это будет работать только для этого вызова и не будет видно в следующем.

Некоторые из таких переменных известны и используются в целом cmake и другими инструментами. Это такие вещи, как CXX, определяющая текущий компилятор C++, или CXX_FLAGS для передачи флагов компилятора и т.д.

Однако у нас есть переменные, специфичные для конфигурации manticore, которые придуманы исключительно для наших сборок.

  • CACHEB - то же, что и опция конфигурации CACHEB

  • LIBS_BUNDLE - то же, что и опция конфигурации LIBS_BUNDLE

  • DISTR - используется для инициализации опции DISTR_BUILD при использовании -DPACK=1.

  • DIAGNOSTIC - делает вывод конфигурации cmake гораздо более подробным, объясняя всё происходящее

  • WRITEB - предполагает LIBS_BUNDLE и, если установлена, будет скачивать исходные архивы для разных инструментов в папку LIBS_BUNDLE. То есть, если выходит свежая версия стеммера — вы можете вручную удалить libstemmer_c.tgz из бандла, а затем выполнить однократный запуск WRITEB=1 cmake ... — он не найдёт исходники стеммера в бандле и скачает их с сайта поставщика в бандл (без WRITEB он скачает их во временную папку внутри сборки, которая исчезнет при очистке папки сборки). В конце конфигурации вы можете увидеть, что доступно и будет использовано, в списке, похожем на этот: -- Enabled features compiled in:

  • Galera, replication of tables

  • re2, a regular expression library

* stemmer, stemming library (Snowball)
* icu, International Components for Unicode
* OpenSSL, for encrypted networking
* ZLIB, for compressed data and networking
* ODBC, for indexing MSSQL (windows) and generic ODBC sources with indexer
* EXPAT, for indexing xmlpipe sources with indexer
* Iconv, for support of different encodings when indexing xmlpipe sources with indexer
* MySQL, for indexing MySQL sources with indexer
* PostgreSQL, for indexing PostgreSQL sources with indexer
### Сборка
cmake --build . --config RelWithDebInfo
### Установка

Для установки выполните:

cmake --install . --config RelWithDebInfo

чтобы установить в пользовательскую (не по умолчанию) папку, выполните

cmake --install . --prefix path/to/build --config RelWithDebInfo

### Сборка пакетов

Для сборки пакета используйте цель package. Она соберёт пакет согласно выбору, заданному опцией -DDISTR_BUILD. По умолчанию это будет простой архив .zip или .tgz со всеми бинарными файлами и дополнительными файлами.

cmake --build . --target package --config RelWithDebInfo

Некоторые продвинутые моменты сборки

Пересборка (обновление) при single-config

Если вы не меняли путь к исходникам и сборке, просто перейдите в папку сборки и выполните:

cmake .

cmake --build . --clean-first --config RelWithDebInfo

Если по какой-то причине это не сработает, вы можете удалить файл CMakeCache.txt, расположенный в папке сборки. После этого шага вам нужно снова запустить cmake, указав папку с исходниками и настроив опции.

Если и это не поможет, просто очистите папку сборки и начните заново.
### Типы сборок

Кратко — просто используйте --config RelWithDebInfo, как указано выше. Это не вызовет ошибок. Мы используем два типа сборок. Для разработки — Debug — он задаёт флаги компилятора для оптимизации и других вещей так, чтобы было удобно для разработки, то есть отладка с пошаговым выполнением. Однако получаемые бинарники довольно большие и медленные для продакшена.

Для релиза мы используем другой тип — RelWithDebInfo — что означает «релизная сборка с отладочной информацией». Она создаёт продакшн-бинарники с встроенной отладочной информацией. Последняя затем выносится в отдельные пакеты с отладочной информацией, которые хранятся отдельно от релизных пакетов и могут использоваться в случае проблем, например, с крашами — для расследования и исправления ошибок. Cmake также предоставляет Release и MinSizeRel, но мы их не используем. Если тип сборки недоступен, cmake сделает сборку noconfig.

Генераторы системы сборки

Существуют два типа генераторов: single-config и multi-config.

  • Single-config требует указания типа сборки во время конфигурации через параметр CMAKE_BUILD_TYPE. Если он не определён, сборка по умолчанию будет использовать тип RelWithDebInfo, что подходит, если вы просто хотите собрать Manticore из исходников и не участвовать в разработке. Для явных сборок следует указать тип сборки, например -DCMAKE_BUILD_TYPE=Debug.

  • Multi-config выбирает тип сборки во время сборки. Его следует указывать с помощью опции --config, иначе будет собрана некая конфигурация noconfig, что нежелательно. Поэтому всегда указывайте тип сборки, например --config Debug.

Если вы хотите указать тип сборки, но не хотите заботиться о том, является ли генератор 'single' или 'multi' конфигурацией — просто укажите необходимые ключи в обоих местах. Т.е. конфигурируйте с -DCMAKE_BUILD_TYPE=Debug, а затем собирайте с --config Debug. Главное, чтобы оба значения совпадали. Если целевой билд-системой является single-config, она использует параметр конфигурации. Если multi-config, параметр конфигурации игнорируется, но правильная конфигурация сборки выбирается по ключу --config.

Если вы хотите RelWithDebInfo (т.е. просто сборку для продакшена) и знаете, что находитесь на платформе с single-config (то есть на всех, кроме Windows) — можно опустить флаг --config при вызове cmake. Тогда будет настроен и использован параметр по умолчанию CMAKE_BUILD_TYPE=RelWithDebInfo. Все команды для 'сборки', 'установки' и 'сборки пакета' станут короче.

Явный выбор генераторов системы сборки

Cmake — это инструмент, который сам по себе не выполняет сборку, а генерирует правила для локальной системы сборки.

Обычно он хорошо определяет доступную систему сборки, но иногда может потребоваться явно указать генератор. Вы

можете запустить cmake -G и просмотреть список доступных генераторов.

  • На Windows, если у вас установлено несколько версий Visual Studio, возможно, потребуется указать, какую использовать,

например: cmake -G "Visual Studio 16 2019" ....

  • On all other platforms - usually Unix Makefiles are used, but you can specify another one, such as Ninja, or Ninja Multi-Config, as:

    Multi-Config`, as: cmake -GNinja ...

    или

    cmake -G"Ninja Multi-Config" ... Ninja Multi-Config весьма полезен, так как действительно является 'multi-config' и доступен на Linux/macOS/BSD. С этим генератором вы можете отложить выбор типа конфигурации до времени сборки, а также собирать несколько конфигураций в одной и той же папке сборки, меняя только параметр --config.

    ### Особенности
  1. Если вы хотите в итоге собрать полнофункциональный RPM-пакет, путь к директории сборки должен быть достаточно длинным для корректной сборки отладочных символов.
    Например, `/manticore012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789`. Это связано с тем, что инструменты RPM модифицируют путь к скомпилированным бинарникам при сборке отладочной информации, и они могут просто перезаписать существующее место, не выделяя дополнительное. Указанный длинный путь содержит 100 символов, чего достаточно для такого случая.

    Внешние зависимости

Некоторые библиотеки должны быть доступны, если вы хотите их использовать.

  • Для индексирования (инструмент indexer): expat, iconv, mysql, odbc, postgresql. Без них можно обрабатывать только источники tsv и csv.

  • Для обслуживания запросов (демон searchd): может потребоваться openssl.

  • Для всех (обязательно!) нужна библиотека Boost. Минимальная версия — 1.61.0, однако мы собираем бинарники с более свежей версией 1.75.0. Ещё более новые версии (например, 1.76) тоже должны подойти. На Windows можно скачать предсобранный Boost с их сайта (boost.org) и установить в путь по умолчанию (т.е. C:\\boost...). На MacOs версия из brew подходит. На Linux можно проверить доступную версию в официальных репозиториях, и если она не соответствует требованиям, собрать из исходников. Нам нужен компонент 'context', можно также собрать компоненты 'system' и 'program_options', они понадобятся, если вы хотите собрать библиотеку Galera из исходников. Посмотрите в dist/build_dockers/xxx/boost_175/Dockerfile для краткого самодокументированного скрипта/инструкции, как это сделать.

На системе сборки должны быть установлены 'dev' или 'devel' версии этих пакетов (например, libmysqlclient-devel, unixodbc-devel и т.д. Названия конкретных пакетов смотрите в наших докерфайлах). На системах запуска эти пакеты должны присутствовать хотя бы в финальных (не dev) вариантах. (devel варианты обычно больше, так как включают не только целевые бинарники, но и различные средства разработки, такие как заголовочные файлы и т.п.).

Сборка на Windows

Помимо необходимых предварительных условий, вам могут понадобиться предсобранные клиентские библиотеки expat, iconv, mysql и postgresql. Их нужно либо собрать самостоятельно, либо связаться с нами, чтобы получить наш сборочный пакет (простой zip-архив, где находится папка с этими целями).

  • ODBC не обязателен, так как это системная библиотека.

  • OpenSSL можно собрать из исходников или скачать предсобранный с https://slproweb.com/products/Win32OpenSSL.html (как указано во внутреннем скрипте cmake FindOpenSSL).

  • Boost можно скачать предсобранный с https://www.boost.org/ releases.

Посмотреть, что собрано

Запустите indexer -h. Он покажет, какие функции были настроены и собраны (явные или обнаруженные — неважно): Built on Linux x86_64 by GNU 8.3.1 compiler. Configured with these definitions: -DDISTR_BUILD=rhel8 -DUSE_SYSLOG=1 -DWITH_GALERA=1 -DWITH_RE2=1 -DWITH_RE2_FORCE_STATIC=1

-DWITH_STEMMER=1 -DWITH_STEMMER_FORCE_STATIC=1 -DWITH_ICU=1 -DWITH_ICU_FORCE_STATIC=1 -DWITH_SSL=1 -DWITH_ZLIB=1 -DWITH_ODBC=1 -DDL_ODBC=1

-DODBC_LIB=libodbc.so.2 -DWITH_EXPAT=1 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DWITH_ICONV=1 -DWITH_MYSQL=1 -DDL_MYSQL=1

-DMYSQL_LIB=libmariadb.so.3 -DWITH_POSTGRESQL=1 -DDL_POSTGRESQL=1 -DPOSTGRESQL_LIB=libpq.so.5 -DLOCALDATADIR=/var/lib/manticore/data
-DFULL_SHARE_DIR=/usr/share/manticore
-DWITH_STEMMER=1 -DWITH_STEMMER_FORCE_STATIC=1 -DWITH_ICU=1 -DWITH_ICU_FORCE_STATIC=1 -DWITH_SSL=1 -DWITH_ZLIB=1 -DWITH_ODBC=1 -DDL_ODBC=1
-DODBC_LIB=libodbc.so.2 -DWITH_EXPAT=1 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DWITH_ICONV=1 -DWITH_MYSQL=1 -DDL_MYSQL=1
-DMYSQL_LIB=libmariadb.so.3 -DWITH_POSTGRESQL=1 -DDL_POSTGRESQL=1 -DPOSTGRESQL_LIB=libpq.so.5 -DLOCALDATADIR=/var/lib/manticore/data
-DFULL_SHARE_DIR=/usr/share/manticore
Windows Manticore Buddy
Last modified: August 28, 2025