Программы создаются с использованием правила<exe>, которое следует общему синтаксису.. Например:

exe hello : hello.cpp some_library.lib /some_project//library
          : <threading>multi
          ;

Это позволит создать исполняемый файл из источников— в данном случае один файл C++, один файл библиотеки, присутствующий в том же каталоге, и другую библиотеку, созданную Boost. Построй. Как правило, источники могут включать файлы C и C++, объектные файлы и библиотеки. Повышаю. Сборка будет автоматически пытаться конвертировать цели других типов.

	Tip
	В Windows, если приложение использует общие библиотеки, и как приложение, так и библиотеки построены с использованием Boost. Построить, сразу запустить приложение невозможно, поскольку переменная<PATH >среды должна включать путь к библиотекам. Это означает, что вы должны либо добавить пути вручную, либо разместить приложение и библиотеки в одном каталоге. См.раздел под названием “Установка”.

Цели библиотеки создаются с использованием правила<lib>, которое следуетобщему синтаксису. Например:

lib helpers : helpers.cpp ;

Это определит целевую библиотеку<helpers>, построенную из исходного файла<helpers.cpp>. Это может быть либо статическая библиотека, либо общая библиотека, в зависимости от значения функции.

Цели библиотеки могут представлять:

Синтаксис для предварительно построенных библиотек приведен ниже:

lib z : : <name>z <search>/home/ghost ;
lib compress : : <file>/opt/libs/compress.a ;

Свойство<name>определяет название библиотеки без стандартных префиксов и суффиксов. Например, в зависимости от системы<z>может относиться к файлу, называемому z.so, libz.a или z.lib и т.д. Функция<search>определяет пути, по которым следует искать библиотеку в дополнение к путям компилятора по умолчанию.<search>может быть указано несколько раз или может быть опущено, в этом случае будут искаться только пути компилятора по умолчанию. Свойство<file>определяет местоположение файла.

Разница между использованием функции<file>и использованием комбинации функций<name>и<search>заключается в том, что<file>является более точным.

Warning

Значение функции<search>просто добавляется к пути поиска линкера. При подключении к нескольким библиотекам пути, указанные<search>, объединяются без учета того, из чего<lib>был выбран каждый путь. Таким образом, данный lib a : : <name>a <search>/pool/release ; lib b : : <name>b <search>/pool/debug ; Если /pool/release/a.so, /pool/release/b.so, /pool/debug/a.so и /pool/release/b.so все существуют, линкер, вероятно, возьмет оба<a>и<b>из одного каталога, вместо того, чтобы найти<a>в /pool/release и<b>в /pool/debug. Если вам нужно различать несколько библиотек с одинаковым названием, безопаснее использовать<file>.

Для удобства допускается следующий синтаксис:

lib z ;
lib gui db aux ;

который имеет тот же эффект, что и:

lib z : : <name>z ;
lib gui : : <name>gui ;
lib db : : <name>db ;
lib aux : : <name>aux ;

Когда библиотека ссылается на другую библиотеку, вы должны включить эту другую библиотеку в список источников. Это будет делать правильно во всех случаях. Для переносимости следует указывать библиотечные зависимости даже для искомых и заранее построенных библиотек, иначе статические ссылки на Unix не будут работать. Например:

lib z ;
lib png : z : <name>png ;

Note

Когда библиотека имеет общую библиотеку в качестве источника, или статическая библиотека имеет другую статическую библиотеку в качестве источника, тогда любая целевая ссылка на первую библиотеку с автоматической ссылкой на ее исходную библиотеку также. С другой стороны, когда общая библиотека имеет статическую библиотеку в качестве источника, первая библиотека будет построена так, что она полностью включает вторую. Если вы не хотите, чтобы разделяемая библиотека включала все библиотеки, указанные в ее источниках (особенно статически связанные), вам необходимо использовать следующее: lib b : a.cpp ; lib a : a.cpp : <use>b : : <library>b ; Это указывает на то, что библиотека<a>использует библиотеку<b>и заставляет все исполняемые файлы, которые ссылаются на<a>, также ссылаться на<b>. В этом случае даже для общих ссылок<a>библиотека не будет ссылаться на<b>.

Требования к использованиючасто очень полезны для определения целей библиотеки. Например, представьте, что вы хотите создать библиотеку<helpers>, и ее интерфейс описан в файле заголовка<helpers.hpp>, расположенном в том же каталоге, что и исходный файл<helpers.cpp>. Затем вы можете добавить следующее в Jamfile, расположенный в том же каталоге:

lib helpers : helpers.cpp : : : <include>. ;

который автоматически добавлял бы каталог, в котором была определена цель (и где находится файл заголовка библиотеки), к компилятору, включая путь для всех целей с использованием библиотеки<helpers>. Эта функция значительно упрощает Jamfiles.

Правило<alias>дает альтернативное название группе целей. Например, дать название<core>группе из трех других целей со следующим кодом:

alias core : im reader writer ;

Использование<core>в командной строке или в списке источников любой другой цели аналогично явному использованию<im >,<reader>и<writer>.

Другое применение правила<alias>— изменение свойств сборки. Например, если вы хотите статически использовать ссылку на библиотеку Boost Threads, вы можете написать следующее:

alias threads : /boost/thread//boost_thread : <link>static ;

Используйте только псевдоним<threads>в ваших джамфилах.

Вы также можете указать требования к использованию<alias>. Если вы напишете следующее:

alias header_only_library : : : :  <include>/usr/include/header_only_library ;

При этом<header_only_library>в источниках будет добавлен только один путь. Также обратите внимание, что когда псевдоним имеет источники, их требования к использованию также распространяются. Например:

lib library1 : library1.cpp : : : <include>/library/include1 ;
lib library2 : library2.cpp : : : <include>/library/include2 ;
alias static_libraries : library1 library2 : <link>static ;
exe main : main.cpp static_libraries ;

<main.cpp>с дополнительными включениями, необходимыми для использования указанных статических библиотек.

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

Basic install

Для установки построенной цели следует использовать правило<install>, которое следуетобщему синтаксису. Например:

install dist : hello helpers ;

Это приведет к тому, что цели<hello>и<helpers>будут перемещены в каталог<dist>относительно каталога Джамфила. Каталог можно изменить, используя свойство<location>:

install dist : hello helpers : <location>/usr/bin ;

Хотя вы можете достичь того же эффекта, изменив целевое имя на</usr/bin>, использование свойства<location>лучше, поскольку оно позволяет использовать мнемоническое целевое имя.

Свойство<location>особенно удобно, когда местоположение не фиксировано, но зависит от варианта сборки или переменных среды:

install dist : hello helpers :
    <variant>release:<location>dist/release
    <variant>debug:<location>dist/debug ;
install dist2 : hello helpers : <location>$(DIST) ;

See also conditional properties and environment variables

Installing with all dependencies

Определение названий всех библиотек для установки может быть скучным.<install>позволяет указывать только исполняемые цели верхнего уровня для установки и автоматически устанавливать все зависимости:

install dist : hello
           : <install-dependencies>on <install-type>EXE
             <install-type>LIB
           ;

Найдите все цели, от которых зависит<hello>, и установите все те, которые являются исполняемыми файлами или библиотеками. Более конкретно, для каждой цели будут рекурсивно найдены другие цели, которые были указаны как источники или как свойства зависимости. Исключением является то, что цели, упомянутые с функцией<use>, не рассматриваются, поскольку эта функция обычно используется для обозначения библиотек только для заголовков. Если набор типов целей указан, будут установлены только цели этого типа, в противном случае будут установлены все найденные цели.

Preserving Directory Hierarchy

По умолчанию<install>правило будет удалять пути из своих источников. Если же источник<a/b/c.hpp>, то<a/b>часть будет проигнорирована. Чтобы правило<install>сохранило иерархию каталогов, вам нужно использовать функцию<<install-source-root>>, чтобы указать корень иерархии, которую вы устанавливаете. Относительные пути от этого корня будут сохранены. Например, если вы пишете:

install headers
    : a/b/c.h
    : <location>/tmp <install-source-root>a
    ;

Будет создан файл</tmp/b/c.h>.

Правилоglob-treeможет быть использовано для поиска всех файлов ниже заданного каталога, что позволяет легко установить целое дерево каталогов.

Installing into Several Directories

Правило<alias>может использоваться, когда цели должны быть установлены в нескольких каталогах:

alias install : install-bin install-lib ;
install install-bin : applications : /usr/bin ;
install install-lib : helper : /usr/lib ;

Поскольку правило<install>просто копирует цели, большинство бесплатных функцийне имеют эффекта при использовании в требованиях правила<install>. Только два из них<dependency>и<dll-path>.

	Note
	(Unix specific) На Unix исполняемые файлы, построенные с использованием Boost. Сборка обычно содержит список путей ко всем используемым общим библиотекам. Для установки это нежелательно, поэтому увеличьте. Build повторно связывает исполняемый файл с пустым списком путей. Вы также можете указать дополнительные пути для установленных исполняемых файлов с помощью функции<dll-path>.

Повышаю. Build имеет удобную поддержку для проведения единичных тестов. Самый простой способ — это правило<unit-test>, которое следуетобщему синтаксису. Например:

unit-test helpers_test : helpers_test.cpp helpers ;

Правило<unit-test>ведет себя как правилоexe, но после создания исполняемого файла оно также выполняется. Если исполняемый файл возвращает код ошибки, система сборки также возвращает ошибку и будет пытаться запустить исполняемый файл на следующем вызове, пока он не запустится успешно. Такое поведение гарантирует, что вы не можете пропустить сбой в единичном тесте.

Существует несколько специализированных правил тестирования, перечисленных ниже:

rule compile ( sources : requirements * : target-name ? )
rule compile-fail ( sources : requirements * : target-name ? )
rule link ( sources + : requirements * : target-name ? )
rule link-fail ( sources + : requirements * : target-name ? )

Им предоставляется перечень источников и требований. Если целевое имя не указано, вместо него используется имя первого исходного файла. Тесты<compile*>пытаются собрать пройденный источник. Правила<link*>пытаются компилировать и связывать приложение из всех переданных источников. Правила<compile>и<link >предполагают, что компиляция/связь удалась. Правила< compile-fail>и<link-fail>предполагают, что компиляция/ссылка не работает.

Существует два специализированных правила для запуска приложений, которые являются более мощными, чем правило<unit-test>. Правило<run>имеет следующую подпись:

rule run ( sources + : args * : input-files * : requirements * : target-name ?
    : default-build * )

Правило строит приложение из предоставленных источников и запускает его, передавая<args>и<input-files>в качестве аргументов командной строки. Параметр<args>пропускается дословно, а значения параметра<input-files>рассматриваются как пути относительно содержащего Джамфила и корректируются, еслиb2вызывается из другого каталога. Правило<run-fail>идентично правилу<run>, за исключением того, что оно ожидает, что пробег не удастся.

Все правила, описанные в этом разделе, при успешном выполнении создают специальный файл манифеста, чтобы указать, что тест прошел. Для правила<unit-test>файлы называются< target-name>.passed, а для других правил —<target-name>.test. Правила<run*>также захватывают весь вывод из программы и хранят его в файле< target-name>.output.

Если<preserve-test-targets>функция имеет значение<off>, то<run>и<run-fail>правила удаляют исполняемый файл после его запуска. Это несколько снижает требования к дисковому пространству для сред непрерывного тестирования. По умолчанию значение<preserve-test-targets>признака<on>.

Можно распечатать список всех тестовых целей (кроме<unit-test>), заявленных в вашем проекте, пройдя опцию командной строки< --dump-tests>. Выход будет состоять из линий формы:

boost-test(test-type) path : sources

Можно обработать список тестов, повысить. Создайте вывод и предпосылку / отсутствие<*.test>файлов, созданных при прохождении теста в таблицу состояний для чтения человеком. Такие утилиты обработки не включены в Boost. Построй.

Следующие функции корректируют поведение метатаргетов тестирования.

Для большинства основных целевых правил, Boost. Build автоматически определяет команды для запуска. Когда вы хотите использовать новые типы файлов или поддерживать новые инструменты, одним из подходов является расширение Boost. Постройте, чтобы поддерживать их плавно, как описано вразделе под названием & #8220; Расширительное руководство & #8221;. Однако, если новый инструмент используется только в одном месте, может быть проще просто указать команды для запуска.

Для этого можно использовать три основных целевых правила. Правило<make >позволяет создавать один файл из любого количества исходного файла, запустив команду, которую вы указываете. Правило 149 позволяет запускать произвольную команду, не создавая никаких файлов. И, наконец, правило<generate >позволяет описать преобразование с помощью Boost. Создание виртуальных целей. Это более высокий уровень, чем имена файлов, с которыми работает правило<make>, и позволяет создавать более одной цели, создавать по-разному названные цели в зависимости от свойств или использовать более одного инструмента.

Правило 152 используется, когда вы хотите создать один файл из нескольких источников, используя определенную команду.<notfile>используется для безусловного выполнения команды.

Предположим, вы хотите создать файл<file.out>из файла<file.in>, запустив командуin2out. Вот как вы это сделаете в Бульваре. Построить:

make file.out : file.in : @in2out ;
actions in2out
{
    in2out $(<) $(>)
}

Если вы бежитеb2и<file.out>не существует, поднимитесь. Постройте командуin2outдля создания этого файла. Для получения более подробной информации об указании действий см.раздел под названием “Повышение. Jam Language”.

Возможно, вы просто хотите выполнить какую-то команду безоговорочно, и эта команда не создает никаких конкретных файлов. Для этого вы можете использовать правило<notfile>. Например:

notfile echo_something : @echo ;
actions echo
{
    echo "something"
}

Единственным отличием от правила<make>является то, что имя цели не считается именем файла. Постройка будет безусловно управлять действием.

Правило<generate>используется, когда вы хотите выразить преобразования с помощью Boost. Создавайте виртуальные цели, а не просто имена файлов. Правило<generate>имеет стандартную подпись основного целевого правила, но вы должны указать свойство<generating-rule>. Стоимость имущества должна быть по форме< @rule-name>, названное правило должно иметь следующую подпись:

rule generating-rule ( project name : property-set : sources * )

и будет называться экземпляром класса<project-target>, именем главной цели, экземпляром класса<property-set>, содержащим свойства сборки, и списком экземпляров класса<virtual-target>, соответствующим источникам. Правило должно возвращать список<virtual-target>случаев. Интерфейс класса<virtual-target>можно узнать, посмотрев файл<build/virtual-target.jam>. Пример<generate>, содержащийся в бусте. Распределение сборки иллюстрирует, как можно использовать правило<generate>.

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

Чтобы использовать предварительно скомпилированные заголовки, выполните следующие шаги:

Пример<pch>в Буст. Распределение сборки можно использовать в качестве ссылки.

Пожалуйста, обратите внимание на следующее:

Обычно, буст. Построение обрабатывает неявных зависимостей полностью автоматически. Например, для файлов C++ все утверждения<#include>найдены и обработаны. Единственным аспектом, в котором может потребоваться помощь пользователя, является неявная зависимость от сгенерированных файлов.

По умолчанию, Boost. Постройте такие зависимости в рамках одной основной цели. Например, предположим, что основной целевой «приложение» имеет два источника: «app.cpp» и «parser.y». Последний источник преобразуется в "parser.c" и "parser.h". Затем, если "app.cpp" включает "parser.h", Boost. Построение позволит выявить эту зависимость. Кроме того, поскольку «parser.h» будет генерироваться в каталог сборки, путь к этому каталогу будет автоматически добавлен для включения пути.

Заставить этот механизм работать через основные целевые границы возможно, но накладывает определенные накладные расходы. По этой причине, если существует неявная зависимость от файлов от других основных целей, должна использоваться функция<<implicit-dependency> >, например:

lib parser : parser.y ;
exe app : app.cpp : <implicit-dependency>parser ;

Приведенный выше пример говорит системе сборки, что при сканировании всех источников «приложения» на наличие неявных зависимостей следует рассматривать цели из «парсера» как потенциальные зависимости.

Повышаю. Build поддерживает кросс-компиляцию с наборами инструментов gcc и msvc.

При использовании gcc сначала необходимо указать свой кросс-компилятор в<user-config.jam>(см.раздел под названием “Configuration”), например:

using gcc : arm : arm-none-linux-gnueabi-g++ ;

После этого, если хост и целевая операционная система одинаковы, например Linux, вы можете просто запросить эту версию компилятора для использования:

b2 toolset=gcc-arm

Если вы хотите настроить таргетинг на другую операционную систему от хоста, вам необходимо дополнительно указать значение для функции<target-os>, например:

# On windows box
b2 toolset=gcc-arm target-os=linux
# On Linux box
b2 toolset=gcc-mingw target-os=windows

Полный список разрешенных имен операционных систем см. в документации пофункции target-os.

При использовании компилятора msvc возможен только кросс-компилятор к 64-битной системе на 32-битном хосте. Пожалуйста, см.раздел под названием “64-битная поддержка”для деталей.