Это невозможно, поскольку Jamfile не имеет «текущего» значения какой-либо функции, будь то набор инструментов, вариант сборки или что-либо еще. Для одной серии Boost. Построить любую заданную основную цель можно с помощью нескольких наборов свойств. Например, пользователь может запросить два варианта сборки в командной строке. Или одна библиотека построена как общая при использовании из одного приложения, и как статическая при использовании из другого. Каждый Jamfile читается только один раз, поэтому обычно нет единого значения функции, доступной в Jamfile.

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

Наиболее вероятным случаем является то, что вы пытаетесь собрать один и тот же файл дважды, с почти одинаковыми, но разными свойствами. Например:

exe a : a.cpp : <include>/usr/local/include ;
exe b : a.cpp ;

Приведенный выше фрагмент требует двух различных компиляций a.cpp, которые отличаются только свойством include. Поскольку функция include объявлена как free Повышаю. Build не создает отдельный каталог сборки для каждого из своих значений, и эти две сборки будут создавать объектные файлы, сгенерированные в одном каталоге сборки. Игнорирование этого и компиляция файла только один раз были бы опасны, так как различные включения могут потенциально привести к компиляции совершенно другого кода.

Чтобы решить эту проблему, нужно решить, должен ли файл быть составлен один или два раза.

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

Многие пользователи хотели бы использовать переменные среды в Jamfiles, например, для управления расположением внешних библиотек. Во многих случаях лучше декларировать эти внешние библиотеки в файле site-config.jam, как это задокументировано в разделе recipes. Однако, если у пользователей уже установлены переменные среды, им может быть неудобно настраивать конфигурацию сайта. Также джем-файлы и использование переменных среды могут быть разумными.

Повышаю. Jam автоматически импортирует все переменные среды в свой встроенный модуль .ENVIRON, чтобы пользователь мог прочитать их оттуда напрямую или с помощью правила helper os.environ. Например:

import os ;
local unga-unga = [ os.environ UNGA_UNGA ] ;
ECHO $(unga-unga) ;

или чуть более реалистично:

import os ;
local SOME_LIBRARY_PATH = [ os.environ SOME_LIBRARY_PATH ] ;
exe a : a.cpp : <include>$(SOME_LIBRARY_PATH) ;

По внутренним причинам, Буст. Постройте все свойства в алфавитном порядке. Это означает, что если вы пишете:

exe a : a.cpp : <include>b <include>a ;

затем командная строка с первым упоминанием a включает в себя каталог, а затем b, даже если они указаны в обратном порядке. В большинстве случаев пользователю все равно. Но иногда порядок включает в себя или другие свойства. Для таких случаев предусмотрен специальный синтаксис:

exe a : a.cpp : <include>a&&b ;

Символы && разделяют значения свойств и указывают, что их порядок должен быть сохранен. Рекомендуется использовать эту функцию только тогда, когда порядок свойств действительно имеет значение, а не как удобный ярлык. Использование его везде может негативно повлиять на производительность.

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

Повышаю. Build пытается автоматически вычислить правильный порядок. Основное правило заключается в том, что если библиотека a «использует» библиотеку b, то библиотека a появится в командной строке перед библиотекой b. Библиотека a считается используемой b, если b присутствует либо в источниках библиотеки a, либо ее использование указано в ее требованиях. Для явного указания отношения use можно использовать функцию . Например, обе следующие строки вызовут появление a перед b в командной строке:

lib a : a.cpp b ;
lib a : a.cpp : <use>b ;

Такой же подход работает и для поисковых библиотек:

lib z ;
lib png : : <use>z ;
exe viewer : viewer png z ;

Для этой цели может быть использовано встроенное правило SHELL:

local gtk_includes = [ SHELL "gtk-config --cflags" ] ;

Вы можете использовать местоположение корня вашего проекта в ваших Jamfiles. Чтобы получить к нему доступ, просто объявите постоянный путь в вашем Джамруте. Файл джема с использованием:

path-constant TOP : . ;

После этого в каждом Jamfile можно использовать переменную TOP.

Если один файл должен быть скомпилирован со специальными опциями, необходимо явно объявить obj Выберите цель для этого файла, а затем используйте эту цель в вашей цели exe или lib:

exe a : a.cpp b ;
obj b : b.cpp : <optimization>off ;

Конечно, вы можете использовать другие свойства, например, для указания конкретных вариантов компилятора C/C++:

exe a : a.cpp b ;
obj b : b.cpp : <cflags>-g ;

Также можно использовать условные свойства для более тонкого контроля:

exe a : a.cpp b ;
obj b : b.cpp : <variant>release:<optimization>off ;

	Note
	Данная статья предназначена для систем Unix.

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

Однако для запуска приложения в зависимости от общих библиотек ОС может потребоваться найти общую библиотеку при запуске приложения. Динамический линкер будет искать в системно определенном списке путей, загружать библиотеку и разрешать символы. Это означает, что вы должны либо изменить системно-определяемый список, приведенный переменной среды LD_LIBRARY_PATH , либо установить библиотеки в системное местоположение. Это может быть неудобно при разработке, так как библиотеки еще не готовы к установке, а загромождение системных путей может быть нежелательным. К счастью, в Unix есть другой способ.

Исполняемый файл может включать в себя список дополнительных библиотечных путей, которые будут искаться перед системными путями. Это отлично подходит для разработки, потому что система сборки знает пути ко всем библиотекам и может включать их в исполняемые файлы. Это делается, когда функция hardcode-dll-paths имеет значение true, которое является значением по умолчанию. Когда исполняемые файлы должны быть установлены, история отличается.

Очевидно, что установленный исполняемый файл не должен содержать жестко закодированные пути к дереву разработки. (Правило install явно отключает hardcode-dll-paths Особенность по этой причине. Тем не менее, вы можете использовать функцию dll-path для добавления явных путей вручную. Например:

install installed : application : <dll-path>/usr/lib/snake
                                  <location>/usr/bin ;

позволяет приложению находить библиотеки, размещенные в каталоге /usr/lib/snake.

Если вы установите библиотеки в нестандартном месте и добавите явный путь, вы получите больше контроля над библиотеками, которые будут использоваться. Библиотека с таким же названием не будет использоваться случайно. Если вы установите библиотеки в системное местоположение и не добавите никаких путей, системный администратор будет иметь больше контроля. Каждая библиотека может быть индивидуально обновлена, и все приложения будут использовать новую библиотеку.

Какой подход лучше всего зависит от вашей ситуации. Если библиотеки относительно автономны и могут использоваться сторонними приложениями, они должны быть установлены в месте расположения системы. Если у вас есть много библиотек, которые могут быть использованы только вашим приложением, имеет смысл установить их в нестандартный каталог и добавить явный путь. Обратите внимание, что руководящие принципы для различных систем различаются в этом отношении. Например, руководящие принципы Debian GNU запрещают любые дополнительные пути поиска, в то время как руководящие принципы Solaris предполагают, что они всегда должны использоваться.

Желательно декларировать стандартные библиотеки, доступные в данной системе. Включение целевой декларации в Jamfile конкретного проекта не очень хорошо, так как расположение библиотек может варьироваться между различными машинами разработки, и тогда такие декларации должны быть дублированы в разных проектах. Решение состоит в том, чтобы объявить цели в Росте. Создайте файл конфигурации site-config.jam:

project site-config ;
lib zlib : : <name>z ;

Напомним, что и site-config.jam, и user-config.jam являются проектами, и все, что вы можете сделать в Jamfile, вы можете сделать и в этих файлах. Итак, вы объявляете идентификатор проекта и цель. Теперь можно написать:

exe hello : hello.cpp /site-config//zlib ;

в любом джемфиле.

В современном C++ библиотеки часто состоят только из файлов заголовка, без каких-либо исходных файлов для компиляции. Чтобы использовать такие библиотеки, вам нужно добавить соответствующие дополнения и, возможно, определения для вашего проекта. Но с большим количеством внешних библиотек становится проблематично запомнить, какие библиотеки являются заголовками, а какие вы должны ссылаться. Тем не менее, с Boost. Создать библиотеку только для заголовков можно как увеличить. Создайте целевую аудиторию, и все иждивенцы могут использовать такую библиотеку, не задумываясь о том, является ли она библиотекой только для заголовков или нет.

Библиотеки только для заголовков могут быть объявлены с использованием правила alias, определяющего их путь включения в качестве части его требований к использованию, например:

alias my-lib
    : # no sources
    : # no build requirements
    : # no default build
    : <include>whatever ;

Включения, указанные в требованиях к использованию my-lib, автоматически добавляются ко всем свойствам сборки иждивенцев. Иждивенцы не должны заботиться о том, является ли my-lib заголовком или нет, и можно позже сделать my-lib в обычную компилируемую библиотеку, не имея при этом деклараций своих иждивенцев.

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

project my : usage-requirements <include>whatever ;
alias mylib ;

Повышаю. Строительство - это название полной системы сборки. Исполняемый файл, который запускает его, является b2. Этот исполняемый файл написан на C и реализует критически важные для производительности алгоритмы, такие как обход графа зависимостей и выполнение команд. Он также реализует интерпретируемый язык, используемый для реализации остальной части Boost. Построй. Этот исполняемый файл официально называется «Boost.Build Engine».

Начало. Двигатель сборки происходит от более раннего инструмента сборки под названием Perforce Jam. Первоначально были незначительные изменения, и имя файла было bjam. Позже, с большим количеством изменений, сходство имен из-за плохого обслуживания пользователей, а также из-за повышения 1.47.0, официальное название исполняемого файла было изменено на b2. Для совместимости по-прежнему создается копия с именем bjam, но во всех случаях рекомендуется использовать новое имя.

Perforce Jam был важной основой, и мы с благодарностью признаем его влияние, но для пользователей сегодня эти инструменты разделяют только некоторые основы интерпретируемого языка.