Кто-нибудь использует boost.build для сборки своих приложений, как-никак это единственная кросс-платформенная система сборки приложений написанных на С++(и не только), даже на одной платформе можно использовать разные компиляторы. Штука полезная и видимо перспективная, но поначалу не очень понятная, куча всяких скриптов вокруг каждого тулсета, непонятные сообщения об ошибках, странный(ооочень странный) язык jam файлов... Но в перспективе можно распрощаться с кучей различных непереносимых форматов мэйк-файлов, файлов проектов и прочего хлама. Поэтому невольно возникает вопрос, стоит-ли изучать сабж, и есть ли опыт использования(не считая сборки boost-a)?

н-ну...

КДЕ4 использует CMake и должен собираться как под винду, так и под линь.
QT-шные про-файлы тоже, в общем-то, кроссплатформенны. Это всё если мы хотим С++.

Лично я boost.build не использую. Планирую в будущем посмотреть на CMake.

Это сообщение отредактировал(а) JackYF - 26.11.2007, 15:36

Lazin, штука, без сомнений, перспективная, но, к примеру, мои опыты закончились, после того, как я не нашёл как указать ему, что нужно линковаться с libboost_regex-somever.

archimed7592, вроде-бы можно, только сегодня про это читал, в период курения мануала на тему сборки под x64 проц. архитектуру.
Просто не всем нужен CMake или qmake, к тому-же QT программы наверняка можно собрать bjam-ом, просто нужно написать Jamfile который бы вызывал uic, moc а потом компилировал-бы.

Lazin, в bbv2 точно есть какая-то поддержка Qt. Только какая(и поддержка ли?) я толком не знаю - так и не нашёл времени разобраться с этой тулзой.

+1

При всё моём уважении к бусту bjam использую (да и то явно уже вообще не использую  ) только для сборки самого буста.


Ой, я бы так не сказал!    

1. GNU Autotools частично портируемы под винду с помощью MSys + MinGW или CygWin. Многие проекты это используют. впрочем это обычно порты с никсов 
2. CMake. Мне правда не понравилось :/
3. Ant - впрочем для C/C++ используется обычно только для сборки нескольких нэтив-методов для явовских приложений. Иногда достаточно многих. Пример - eclipse.
4. SCons - собсно моё любимое  Зависит только от питона. Питон можно найти под любую разумную платформу. Для работы чистого SCons с Qt есть небольшой модуль, впрочем мне в итоге гораздо больше понравился (можно сказать, форк сконса) Waf. Поддержка Qt, в частности, встроенна в Waf. Вообщем, на мой взгляд, очень приятная вещь.

SCons и waf - очень интересные инструменты, но насколько я понял не сильно распространенные, на данный момент))

Просто они молодые очень 

http://code.google.com/p/waf/wiki/Projects - проекты, юзающие Waf.

http://www.scons.org/wiki/SconsProjects - проекты, юзающие Scons.

KDE Team изначально для четвёрки планировали SCons (в итоге перешли на CMake). Собственно это и есть по сути предыстория создания Waf 

bjam кстати тоже не дюже распространён   

SCons смотрел, как-то в чистом виде не понравился... на waf взглянуть надо.
И на CMake...

А почему, если не секрет. Взглянул(бегло), функции те-же что и у CMake. Мне к примеру пайтон больше улыбается, чем какой-то очередной скриптовый язык, используемый CMake...

Вообще говоря, до сих пор "язык", применяющийся в юниксовых Makefile'ах, мне улыбается больше всего. Потому что он только под мэйкфайлы и заточен, + учитывает многие нюансы. Но, увы, как только твоё приложение нужно распространять, ручные мэйкфайлы уже мало годятся. А, имхо, autotools - ужас и страх.

Поэтому я уже довольно-таки давно ищу приемлемую для меня альтернативную систему сборки.

Они в принципе достаточно похожи. Хотя Waf вводит много приятных вещей в плане написания скриптов (всмысле их структуры), больше всяких инструментов интегрировано + вывод приятней 

Минус cmake хотя бы в том, что это обёртка над обычным мейком. Не совсем понимаю смысла.


Мне тоже. На питоне свою мысль выразить легче иногда. Может, конечно, у меня мышление не слишком деларативное?  

Обёртка над make мне и надо. Язык хороший, но много чего хочется автоматизировать.

Посмотрел я на waf. Нет, не то. Ещё ни одна система, кроме, собственно, Makefileов чистых, не предоставила мне нормальных примеров рабочих Makefile или их аналогов. В example какие-то куцые приложения на 10 строк, с добавлением 1-2 опций компилятору. Тьфу...

Мне требуется три варианта сборки проекта, с возможностью указания любых ключей компиляторам, а не только тех, что "известны" билд-системе, с возможностью выполнять шелл-код в любых местах сборки. За исключением cmake, про который я пока ничего не знаю, у меня кандидатов на билд-систему нет, потому как всё остальное пока идёт гулять лесом.

Как неплохой вариант - посмотреть на SConstruct-ы, wscript-ы реальных готовых проектов.


Variants в вафоской вики.


Само собой.


Можно и шелл. Но проще писать непосредственно на питоне 

В том-то собственно одна из основных фишек (для меня по крайней мере) сконса/вафа/рейка|etc. (последней на руби, потому смотреть не стал - питон ближе  ) - полная свобода действий. Все возможности полноценного скриптового языка перед нами. Это с точки зрения написания билд-скриптов.

посмотрел на waf xmms2. Пока что - не лежит душа.


спасибо, нашёл.


да вот что-то не очень заметно. В примерах есть переопределение CFLAGS там, CXXFLAGS и т.д. Указание опций компилятору, вызов компилятора я не увидел.


Наверное, это хорошо. Но - не знаю я питон. Возможно, позже оценю .

Ну, на вкус и цвет... Просто мне питон нравился всегда. И его удачное применение - считаю это хорошо 


Речь шла про опции 

А так - можно и вызвать. Хотя лучше в таком случае создать свой tool (см ${WAF_DIR}/wafadmin/Tools), зарегить и цевильно его использовать. Просто тулы - это несколько больший уровень абстракции, чем простой вызов. Например, они предоставляют набор опций. Скажем, для любой программы, использующий C/C++ (стандартная текущая вафоская поставка поддерживает gcc/g++ и msvc, доступен параметр (при сборке) -d (--debug-level) со значениями ultradebug, debug, release, optimized. По waf --help выполненному в папочке с нужным wscript в числе прочего увидим эту опцию.

Ещё большоё преимущество над всеми мэйк-обёртками - это некоторое повышение скорости сборки (в том числе более прогрессивное распараллеливание сборки). Про автотулзы я вообще молчу. Когда создание config.h и мэйкфайла идёт больше, чем сборка самой программы - чисто идеологически раздражает.

В последнее время, появилось много (неплохих) билд-систем. Так что, каждый может выбрать для себя, пожалуй.

да, поэтому я и не люблю autotools.



возможно. Я придирчив.


ну дык опции сборки я указываю при вызове компилятора, не так ли?

Просто есть уже тул-интеграторы для компиляторов C/C++ вообщем и конкретные - для gcc/g++ и msvc (только что глянул - ещё оказывается и для сановского компилера тоже). Вызываемая строка строится там так:


Все ${...} можно задать через conf.env.

Если принципиально не нравиться - можно любую команду выполнить вручную. В вафоском модуле Runner есть небольшой враппер exec_command для фулл-портабельного выполнения команд. Некоторые билд-тулы юзают его непосредственно. Большинство искользуют более высокий уровень абстракции - класс Action.

У всех этих билдеров есть одна общая проблема - на целевой системе надо что-то ставить! В одном случае это питон+scons/waf, в другом cmake, в третьем boost.build... А вот с autotools этой проблемы нет - если у вас есть минимальный набор UNIX утилит, то configure заработает и скажет, что надо доустановить. Хотя, некоторые недоразвитые ОС данных утилит в штатной поставке не имеют (более того, даже полнофункциональных аналогов), но это уже на совести их авторов.

Что ж, ясно  Главное, что теперь я знаю об этой системе и буду принимать во внимание.

Авось выучу питон, тогда будет легче 

Для waf поставляется configure-обёртка, которая чекает питон и (затем) ваф.

Добавлено через 3 минуты и 29 секунд
Тем более, как где-то было правильно замечено - питон на никсах становится таким же стандартным скрипт-языком, как и перл. То есть и мэйка может в готовой поставке не быть  И это нормально - для недеволперской среды. А для девелоперов/пэкеджеров установка билд-системы - это нормально.