Бывают моменты, когда вы хотите контролировать, строится ли цель сборки или нет, основываясь на том, какие функции поддерживает компилятор. Например, предположим, что у вас есть тест-файл «test_constexpr_128.cpp», который требует трех ключевых функций для создания:
constexpr ключевое слово, обнаруженное BOOST_NO_CXX11_CONSTEXPR.- Пользователь определил литералы, обнаруженные BOOST_NO_CXX11_USER_DEFINED_LITERALS.
__int128 тип данных, обнаруженный BOOST_HAS_INT128.
Понятно, что если эти функции не поддерживаются компилятором, то просто нет смысла даже пытаться построить тестовую программу. Основными преимуществами являются:
- Более быстрое время компиляции - конфигурация сборки использует легкие тесты, результаты которых также кэшируются.
- Меньше шума в сборке вывода - нет никаких причин, чтобы столкнуться со страницами считывания шаблона, если мы знаем, что файл никогда не может компилироваться.
- Меньше шума в результатах онлайн-теста - тест покажется пустым, а не провалом в онлайн-тестной матрице.
- Лучший опыт для конечных пользователей, строящих все Boost, если те библиотеки, которые не могут быть построены для текущего целевого компилятора, просто пропущены, а не создают страницы вывода ошибок.
Возвращаясь к нашему примеру, тестовый случай, вероятно, выполняется в его Jamfile через правило «запуска»:
run test_constexpr_128.cpp ;
Теперь мы должны сделать эту цель условной на необходимые особенности. Мы можем сделать это, сначала импортировав необходимое правило в начале Jamfile:
import path-to-config-lib/checks/config : requires ;
Если предположить, что испытательный случай находится в обычном каталоге:
libs/yourlib/test
тогда правило импорта будет фактически:
import ../../config/checks/config : requires ;
Затем добавить правило «требующих» к разделу требований цели:
run test_constexpr_128.cpp
: : : #requirements:
[ requires cxx11_constexpr cxx11_user_defined_literals int128 ] ;
Обратите внимание, что несколько аргументов могут быть добавлены к требуемому правилу, и что они всегда такие же, как и Boost. Настроить макроимя, но в более низком случае и с boost_no_ или boost_has_ удалить префикс.
При построении приведенного примера вы увидите в начале процесса сборки результаты конфигурации, например, GCC в режиме C++11:
- Boost.Config Feature Check: int128 : yes
- Boost.Config Feature Check: cxx11_constexpr : yes
- Boost.Config Feature Check: cxx11_user_defined_literals : yes
Это все, что есть в этой удобной функции, если в любое время вы не уверены в именах-тестах, которые вы можете передать правилу «требования», а затем искать Посла. Настройка макро-интересов в libs/config/checks/Jamfiles.v2, и название проверки функции будет следовать за ним.
И, наконец, эта функция построена вокруг Boost. Строить построенное в правиле check-target-builds, которое может быть использовано для проведения более обобщенного тестирования функции сборки. Проверки в этой библиотеке предоставляются в качестве удобной короткой руки без необходимости писать тестовые случаи самостоятельно.
