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

чё-то нифига не понятно чем это поделие лучше make

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.

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

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

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

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

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

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

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

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

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

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

Jam, FTJam, Boost.Jam...

Кстати говоря Boost в процессе перехода с Boost.Jam на CMake.

head

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

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

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

> Кстати говоря Boost в процессе перехода с Boost.Jam на CMake.

Пруфлинк?

Кстати говоря Boost в процессе перехода с Boost.Jam на CMake.

Пруфлинк?

https://svn.boost.org/trac/boost/wiki/CMake

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

> 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, и время сборки летит в минус. Хотя писать их проще, признаю.

4.2

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

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

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

> - 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.

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

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

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

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

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

make, cmake, jam, ... - да ну их на фиг, вон как надо.

А если серьёзно, то чем оно лучше cmake?

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, и чОрт лысый в комплекте.

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

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

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

SCons круче всех. Ваш К.О.

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

subj

:)

плагиат...

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

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

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

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

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

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

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

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

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

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

Улучшенная версия сабжа:

http://gitorious.org/kjam