LINUX.ORG.RU

Jam - система создания программ из файлов исходного кода

 jam


0

0

В данном цикле статей рассматривается make-подобная система сборки программ из файлов исходного кода.
В первой статье описываются общие характеристики Jam, структуры файлов Jambase и Jamfile и обработка дерева каталогов, содержащих файлы исходного кода.
Во второй статье основное внимание будет уделено правилам создания выполняемых программ и библиотек, а также процедурам компиляции и сборки.
Третья, заключительная статья цикла будет посвящена управлению файлами в системе Jam, то есть, копированию и установке готовых программ и вспомогательных файлов; кроме того, будет приведён пример файла Jamfile для создания приложения.

>>> Подробности

★★★

Проверено: JB ()

долго втыкал в заголовок новости и пытался понять, что такого нового в принципе создания программ из файлов исходного кода

heisenberg ★★
()
Ответ на: комментарий от Alphaer

The main differences between Jam and Make are as follows.

- Jam uses 'Jamfiles' instead of 'Makefiles'.
- Jamfiles do not normally contain toolset-specific rules or actions. They are thus portable among distinct compilers.
- Jamfiles are a lot simpler than Makefiles to write and understand, while providing the same functionality, and much, much more.

hdclnr
()

Jam, на первый взгляд, лучше make. Например, тем, что он один, а несовместимых диалектов make множество. Опять же кроссплатформенность - это тоже плюс.

Однако Jam не понравился какой-то нестройностью языка. Для простого применения это неважно, а вот попытка сделать что-то нестандартное (которые делалось на GNU make лёгким движением руки) выливается в дикую головную боль и кучу запутанного кода.

С огромным облегчением ушёл с jam на cmake, у которого соотношение плюсов к минусам гораздо лучше и который развивается, в отличие от.

eliterr
()

>система создания программ из файлов исходного кода
Сначала подумал, что это компилятор.

fractaler ★★★★★
()

Заголовок мозговыносящий.

Jam - система создания программ из файлов исходного кода


Этим всю жизнь занимался компилятор.

pevzi ★★★★★
()
Ответ на: комментарий от eliterr

>Jam, на первый взгляд, лучше make. Например, тем, что он один, а несовместимых диалектов make множество.

Не «Jam один», а «Jam еще один».

kraw ★★★★
()

head

Да, заголовок доставляет ))

Удивительное рядом ))

vitalif ★★★★★
()

такие штуки называцо кагбы «системы сборки»

anonymous
()

Для CentOS 5 jam 2.5 нашел в EPEL. Пошел смотреть, что за система.

lystor ★★
()
Ответ на: комментарий от eliterr

> Jam, на первый взгляд, лучше make.

во-первых, он заметно быстрее по бенчмаркам: http://gamesfromwithin.com/the-quest-for-the-perfect-build-system

Например, тем, что он один, а несовместимых диалектов make множество.

Один, говоришь? Основных мейк-диалектов 3: Gnu Make, BSD make, NMake под msdev :) А Jam-ов:

1. Оригинальный by Christopher Seiwald из Perforce. Используется с небольшими изменениями (портирование) в системе сборки ОС Хайку.

2. FtJam, FreeType Jam

3. Boost::Build, Boost:Build v2. Язык удобнее, но судя по бенчмаркам он сильно медленее. В v2 вообще на Питон перешли. Итого: неясно, зачем этот форк вообще нужен

4. KJam, коммерческий, первые n запусков (или с ограничением по дате) — бесплатно. Сильно быстрее оригинала.

Однако Jam не понравился какой-то нестройностью языка. Для простого применения это неважно, а вот попытка сделать что-то нестандартное (которые делалось на GNU make лёгким движением руки) выливается в дикую головную боль и кучу запутанного кода.

Он не то чтобы нестройный, он сильно другой по другим принципам. Во-первых, в Make Makefile парсится по нескольку раз из-за интерполяции переменных (вроде $(sh foo.sh)) , а в Jam — только один раз в начале. Jam однопроходной, поэтому в итоге получается быстрее Make. Во-вторых, давно известно, что Recursive Makefiles considered harmful, но GNU Build System с autotools явно на это рассчитана. Make по нескольку раз перечитывает Makefile в подкатологах, Jam сразу читает всё и парсит всё за один проход.

В-третьих, отсюда разница в логике языка: все переменные уже отпарсены раз и навсегда, остаётся добавлять действия/правила для того, для чего в Make использовались цели и переменные. В итоге, Jam, как и Scons становится более «императивный», чем «декларативный» по сравнению с Make (хотя в Scons/Waf/ANT/Boost::Build v2 тут уже явный перебор, ИМХО)

Запутанность кода — это да, зло. Мучался добавить простую вещь как тесты или нестандартный компилятор (например, язык D) — нужно перерыть всю документацию, примеры, статьи на сайте Perforce , после чего становится немного понятно, какое правило нужно напейсать.

огромным облегчением ушёл с jam на cmake,

И в итоге CMake порождает те же considered harmful Makefiles, и время сборки летит в минус. Хотя писать их проще, признаю.

anonymous
()
Ответ на: 4.2 от anonymous

Сам по ссылке читал? В бусте последний раз cmake использовался год назад.

И тем не менее, в Fedora каким-то невероятным образом умудряются собирать boost cmake'ом =).

Deleted
()
Ответ на: комментарий от hdclnr

> - Jamfiles do not normally contain toolset-specific rules or actions. They are thus portable among distinct compilers.

Вах.. А как же дефолтный набор Jamrules в поставке самого Jam? Или имелось в виду: конечные Jamfile сборки проекта не содержат компиляторно-специфических правил/действий, исключительно потому, что дефолтный встроенный набор по умолчанию из Jamrules УЖЕ корректно определил нужный компилятор/язык/зависимости вроде .h из .c ?

В итоге и получается, что

Jamfiles are a lot simpler than Makefiles to write and understand,

Правда, добавлять что-то в этот набор Jamrules непросто (например, свой нестандартный компилятор, свой транслятор, собираемый системой сборки, новый язык/компилятор, и т.п.).

В Waf/Scons вроде попроще расширять получалось.

Получается такой tradeoff: 1. Makefile черезчур детальный. Поэтому его не пишут руками, а используют autotools/cmake. 2. Jam/Waf/Scons содержит разумные настройки/правила тулчейна, автоопределяемые по дефолту. Зато расширять их — сложнее, чем декларативный Makefile.

anonymous
()

Интересно, а насколько сложно/просто заставить CMake генерировать на выходе набор не Makefiles, а Jamfiles? В итоге бы все выиграли — собиралось бы быстрее, и не надо эти правила каждый раз руками писать.

anonymous
()
Ответ на: комментарий от anonymous

Рад за федоровцев, только откуда следует, что буст в процессе перехода?

Когда-то давно они собирались перейти на CMake (пруф есть где-то в их списках рассылки, сходу нагуглить не могу). Я и подумал, что раз в федоре начиная с 13-й версии начали собирать буст цмяком, то у них есть прогресс в это направлении. Похоже я ошибся.

Deleted
()
Ответ на: комментарий от Deleted

Смущает по ссылке, что это 1.41. Сейчас буст как бы 1.44. Кто его знает, вдруг перепишут boost::build с питона на руби, поломают что-то в свежей системе сборки и это из версии 1.41 перестанет работать с последним актуальным бустом из репозитория.

anonymous
()
Ответ на: комментарий от AlexVR

CMake — это не система сборки, это генератор Makefiles под нужную платформу, вроде autotools, только более навороченней (CDash; CTest; CPack, генерирующий инсталляторы и бинарные пакеты).

Jam — это система сборки, как и Make, только без некоторых его «ошибок реализации».
Поэтому оно быстрее (см. бенчмарки с gameswithin, и общие соображения относительно однопроходности и «considered harmful»).

С другой стороны, язык Make более «декларативный», а Jam — более «императивный».
Поэтому Makefiles писать проще (пример: FreeBSD ports), но всё равно их руками не пишут, а используют генераторы autotools/CMake/Cook/Bakefiles/whatever ...

Причина 1: обленились.
Причина 2: Они разные функционально. Например, с точки зрения жизненного цикла, Make, сгенерированный autotools умеет make dist, make check, и т.п. Поэтому пользоваться autotools/Cmake/Maven «полезнее» чем «голым» mk/make/jam/ant — тут тебе и запуск тестов, и деплоинг, и автодоки, и аплоадинг вроде mvn site, и чОрт лысый в комплекте.

anonymous
()
Ответ на: комментарий от Deleted

Когда-то давно они собирались перейти на CMake (пруф есть где-то в их списках рассылки, сходу нагуглить не могу). Я и подумал, что раз в федоре начиная с 13-й версии начали собирать буст цмяком, то у них есть прогресс в это направлении. Похоже я ошибся.

судя по логам комитов переход загнулся толком не начавшись

SlothSpot
()
Ответ на: комментарий от anonymous

Сам под макось собирал недавно Boost cmake'ом.

Kosyak ★★★★
()

Jamshoot одобряет, насяльника!

subj

anonymous
()
Ответ на: комментарий от anonymous

есть ещё как минимум HBJam, используемый в Harman/Becker. то ещё счастье

jtootf ★★★★★
()

> система создания программ из файлов исходного кода

Это такой новояз?

bbk123 ★★★★★
()

Какая иновационная нано-программа.

ShTH
()

Если кто не понял - Make не является системой сборки. Это просто система автоматизации действий. Но в своё время решили не делать велосипеды, а просто воспользоваться готовым. И исторически сложилось так, что Make уже много лет как используют для продвинутой и универсальной сборки.

Quasar ★★★★★
()
Ответ на: комментарий от anonymous

>Jam — это система сборки, как и Make, только без некоторых его «ошибок реализации».

Поэтому оно быстрее (см. бенчмарки с gameswithin, и общие соображения относительно однопроходности и «considered harmful»).


Вот мне честно пос..ать насколько оно быстрее, потому что 99.(9)% времени занимает компиляция и линковка, а не исполнение мейка.

CMake делает Makefiles => Jam не нужно

anonymous
()
Ответ на: комментарий от anonymous

А вы много кода в файлы не пихайте. А потом посмотрите кто чего и сколько.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.