Какую систему автоматической сборки Вы применяете?

Не понял зачем писать Makefile-ы если можно один раз написать Makefile на всю жизнь. В моих проектах один Makefile. Конечно это ограничение переносимости но под GNU/Linux самое то.

А вот то что лабает IDE даже Makefile-ом назвать нельзя, это фуфло разбухшее на солнышке. Мегабайт для такого файла - норма. Когда хватает const 13k для любого проекта.

cmake

пишу руками Makefile или пишу скрипты которые пишут Makefile

Makefile

Велосипедистов-Makefile писателей, я смотрю, тут много. У вас у всех такие простые проекты что Makefile хватает?

Пока пишу руками. Надеюсь в скором будущем осилить какую-либо из систем.

cmake

Пишу руками Ant-Makefile-ы. :)

> <ответ начало><точно><запятая><пробел><именно><пробел><так><ответ конец>

</ответ конец></так></пробел></именно></пробел></запятая></точно></ответ начало>

fixed.

> У вас у всех такие простые проекты что Makefile хватает?

Со сложностью проекта это связано косвенно, вообще-то.

qmake

Я так понял, что на лоре все программисты?

> > У вас у всех такие простые проекты что Makefile хватает?

> Со сложностью проекта это связано косвенно, вообще-то.

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

> Со сложностью проекта это связано косвенно, вообще-то.

Смотря что считать сложностью. Если к-во *.c файлов в каталоге, то никак не связано. А если проект состоит из достаточного количества библиотек, которые надо правильно собрать и слинковать между собой, использует достаточное количество зависимостей, которые надо правильно найти, имеет достаточное количество опций, которые влияют не только на #define, но и на зависимости и различные варианты сборки, когда для проекта есть набор тестов, которые надо собрать, запустить и обработать выхлоп, когда на стадии configure надо проверить много нетривиальных вещей, когда все это хочется при необходимости сразу собрать в release/debug/profile/release-with-debug-info под Linux, *BSD, MAC и Windows, то связано напрямую. Просто возьми из этого списка один пункт, реализуй на make, посмотри что получилось и убейся.

использую rake и для руби-специфичных, и когда нужно сгенерить makefile. лень-матушка.

-DSSS (специфичная для языка)
-ANT
-пишу скрипты

>> ><В>< ><xml>< ><нет>< ><плюсов><><,>< ><там>< ><только>< ><уголки><

<ответ начало><точно><запятая><пробел><именно><пробел><так><ответ конец>

забыл <fixed/>

<aslo captcha="moning"/>

самописная система сборки с поддержкой параллельной компиляции

Что-то маловато народу scons юзает, жаль...

Предпочитаю cmake. В исключительных случаях пишу Makefile руками или ваяю сборочный скрипт. Ну и для qt -- qmake.

Меня терзают смутные сомнения, что не так давно подобный опрос уже был, и я в нём участвовал %)

Родной, что-то ты больно желчный. Читай выше. Писалось что если не нуна переносимость (мне не нужна, только GNU/Linux (ну не трахает меня win*, *bsd и прочая)) то самое оно, с отслеживанием зависимостей между модулями, отслеживанием версий CVS (git/svn не использую), автоформирование отчёта в наш отчётник и прочая 13kib вне зависимости от сложности проекта, там в подпроектах просто ln ../Makefile . автоматически ставится. Все улучшения Makefile-а стазу же доступны во всех проектах.

Так что убейся сам латентный виндузоид. Но ты прав что если поставить ТОБОЙ обозначеную цель, то да, извращаться придётся дай бог.

Кроме того я и сам не доволен некоторыми аспектами GNU/Make. В частности в depend-ах нет встроенной сортировки по mtime, очень надо, но можно и внешними уилитами бахать. А патчи они не принимают, что-то или не одобряют.

> самописная система сборки с под...

Велосипедист?

Я доверяю IDE. А еще люблю IDE, которые генерят Makefile'ы чтоб вручную подправить если что... :)

Но больше всего на свете люблю _кросплатформенные_ IDE и кросплатформенные проекты в едином для всех ОС формате проекта, настроект и т.д.

103 лулза, зачет

> Что-то маловато народу scons юзает, жаль...

Ничего не жаль. scons во многом хуже даже autotools.

> если поставить ТОБОЙ обозначеную цель, то да, извращаться придётся дай бог

Да вам и без МОЕЙ цели, я смотрю, изрядно приходится :))

Если вам хватило Makefile, то:
- Ваш проект действительно простой. Очень.
- Это не значит, что нельзя сделать еще проще.

> > Что-то маловато народу scons юзает, жаль...

> Ничего не жаль. scons во многом хуже даже autotools.

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

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

autotools не рассматривается вообще, потому что он помойка. Но помойка по крайней мере логичная. SCons же больше библиотека для питона, чем сборочная система - половину всего надо писать руками, ибо из коробки оно ничего не умеет. Указать CC/CFLAGS/CXX/CXXFLAGS по умолчанию нельзя, только при соответствующей поддержке в SConstruct. Искать зависимости оно не умеет - приходится для каждой системы писать свой if. Да и вообще, по умолчанию оно очищает environment, из-за чего ccache сходит с ума. Косяков там _очень_ много, чтобы в этом убедиться достаточно взглянуть на SConstruct любого нетривиального проекта. Например, игрушки battletanks, pingus, freera. Зацени, что происходит там в SConstruct: определяются опции для CC/CXX и флагов, которые должны быть по умолчанию. Определяются кошмарные питоновские классы, выводятся руками ошибки. Спасибо, уж лучше sh.

cmake лишен этих недостатков. Все необходимые опции там поддерживаются по умолчанию и настраиваются через комманндую строку (-DCMAKE_*), но что характерно, это единственная сборочная система которая позволяет собрать софт на FreeBSD и MacOS вообще без изменения скриптов и указания параметров. Зависимости он ищет сам, синтаксис идеален. Опять же ctest и cpack.

Судя по всему за cmake больше всего голосовали кросплатформеры, кто еще и под винду собирает проекты.

В этом плане самое кросплатформенное средство (не считая жабы)

Да нет, просто cmake чрезвычайно удобен. А Windows и Java не нужны.

Угу, scons и правда сносит переменные окружения по дефолту. Про зависимости - это вопрос к реализации конкретных builder-классов. Пока я не жаловался. Хотя пока обходился лиьками, которые сами по себе нормально переносимы и компиляются на венде и линухе одинаково. Хотя поддерживаемого добра у cmake побольше, да.

Зато со scons не нужно учить ещё один недоязык конфигов. Да и вообще, софтина, которая генерит файлы для других систем сборки кажется слишком толстой. А кстати, тяжело там свой обработчик зависимостей сделать? Или ждать ебилдов нужно? Я вот глядя в вики cmake вижу жесть на эту тему. А в scons - это просто питоновский класс со стандартным интерфейсом.

Про ctest и cpack можно поподробнее? Чем оно лучше тестовых программ, которые можно прогнать и поглядеть результат. На это хвтаит и Makefile`а. Что они в cmake`е там придумали, чего не умеет, например, boost::test + старый добрый make?

> Зато со scons не нужно учить ещё один недоязык конфигов.

Я бы сказал, это для scons надо учить недоязык питон. На самом деле по простоте синтаксиса cmake очень сильно выигрывает у scons - на одно действие 1 строчка, без лишних скобок, словарей, клонирования environment'а и передачи его в SConstruct'ы, никакой писанины своих классов (это вообще дикость). Кстати, еще из плюсов - все таргеты доступны в любой точке проекта, не надо делать

xxx = SConscript
Sconscript(..., exports = ['xxx'])

cmake более декларативен. Пока на SCons пишется программа, собирающая другую программу, на CMake пишется описание проекта, которое никогда не потребует лишнего кода.

> Да и вообще, софтина, которая генерит файлы для других систем сборки кажется слишком толстой.

Наоборот cmake не загружен функциаям, с которыми отлично справяется make.

> А кстати, тяжело там свой обработчик зависимостей сделать?

Нет, в общем случае это 2 команды - FIND_PATH для поиска инклуда и FIND_LIBRARY для поиска библиотеки. Сразу указывается возможные названия, пути и суффиксы путей (например, libavformat может быть в ${PREFIX}/include/ffmpeg а может быть в ${PREFIX}/include/libavformat). И это сразу работает под _всеми_ системами, не надо думать даже, .dll там или .so, никаких ветвлений.

> Или ждать ебилдов нужно?

Нет, отсутсвие файндера в комплекте CMake совершенно не проблема.

> Я вот глядя в вики cmake вижу жесть на эту тему. А в scons - это просто питоновский класс со стандартным интерфейсом.

Все как я сказал, никакой жести. Вот класс писать - действительно жесть.

> Про ctest и cpack можно поподробнее? Чем оно лучше тестовых программ, которые можно прогнать и поглядеть результат.

ctest не заменяет тестовые программы, а контролирует их выполнение. Просто грамотная замена очередному самописному велосипеду + дополнительнык плюшки.

А cpack сам генерит пакеты (deb, nsis, rpm, tgz/tbz2, zip).

Все это позволяет полностью автоматизировать сборку, тестирование и создание пакетов.

Какие могут быть сомненья --- скрипты и Makefile'ы.

сейчас Cmake юзаю, вполне удобная штука и достаточно понятная. Иногда ещё qmake пользую ибо он проще некуда и блин очень быстро makefile генерит, не то, что всякие autotools

jam - явный аутсайдер :)

Сам регулярно только ant юзал, а так - emerge... «Другой вариант», в общем, выбрал...

Под виндой ещё когда-то руками Makefile писал :)

ant + IJ Idea

Кто все эти люди?

Результаты опроса обнадеживают. Еще немного, и cmake вытеснит убогий autohell. scons в ауте где ему, как уже сказали, самое место. А пионеров, пишуших руками Makefile, можно вообще не считать, для институстких лаб больше и не нужно.

CMake фанбой детектед.

"Какую систему автоматической сборки Вы применяете?

"- никакой, "

Кстати о cmake. Dart вообще живо?

cmake, qmake где ничего, кроме Qt, не нужно.

а ещё люблю cmake за то, что он хотя бы примерно показывает степень собранности, да и вообще аккуратно и красиво в консоль флудит, как то приятно даже смотреть, да и оценить время сборки проще

ололо
"а что это?" лидирует

собираю руками

Ничего сложного не пишу, потому хватает в ручную написанных Makefile

Пишу Makefile'ы :-)

А где же bsd make с его кучкой вспомогательных Makefile-ов, которые позволяют декларативно, быстро и без напряга наваять могучий Makefile на проект?

Для работы сам лично писал подобный набор мейкфайлов для gnu make, ну, понимаете ли, по той простой причине, что синтаксис bsd make никто у нас не знает, или, проще говоря, стая ляпиксоидов, ничего кроме своей иконы не видящих.

В результате мейкфайлы обслуживают систему тестирования, gch-хедер, 3 под-проекта, раздельную компиляцию в ${OBJDIR} и прочией феньки-красивости. Все, вроде как, остались довольны.

И всё это без оверхедов в виде мегобайтовых скриптов, ожиданий sh autogen.sh && cd objs && ./configure после чекаута, и только потом make.