autotools, Ъ, олдскульно и канонично, все их используют

cmake или чистый make. Автолулз зачастую неюзабелен и весьма криво ведёт себя с кодом от других версий.

make. Местами конечно приходиться изголяться (рекурсивные вызовы, шаблонные правила), но вещь годная.

autotools, хотя да, надо бы сваливать на CMake.

cmake

Поддерживает вижуальник и вижуальниковый нативный компилятор, поддерживает эклипс и гцц, поддерживает кросс-компиляцию.

Порог вхождения на порядки ниже, чем у автотулзов.

смотрю в сторону cmake

Ну и всё, смотри и вкуривай дальше

make или qmake.

autotools

cmake. очень удобная вещь.

waf. Он забавный.

CMake - это не система сборки, а генератор Makefile'ов и тд.

таки пользую make. сила привычки)

остановлюсь на cmake. всем спасибо

Использую CMake. Потому что это первое, что осилил.

CMake не устраивает тем, что не приучает ни к какому из стандартов. Те же autotools соответствуют GNU-стандарту для системы сборки (предоставление целей dist, distclean, check, ...), хотя многим (и мне) autotools кажется сложнее CMake.

С кроссплатформенностью в CMake проще на первый взгляд, хотя у autotools (сейчас в Википедии глянул) есть вроде бы удобные способы кросскомпиляции.

В общем, сам я постоянно думаю о других системах сборки, но с CMake как-то пока живу.

автотулз, но голову поломать придется при первом старте. далее всё будет «само» ;) вот толковый быстро-старт. по нему и разобрался.
http://markuskimius.wikidot.com/programming:tut:autotools

для опенсорс проектов использую autotools, потому что на все случаи жизни есть готовые макросы, и куча проектов где подсмотреть как что делать. ну и потому что юзеру кроме make для сборки не надо никакие cmake/qmake/scons/python и пр. устанавливать, и разбираться как их запускать. но порог вхождения для девелопера высок, и граблей немало, которые придется учиться обходить.

для очень мелких проектов просто make. потому что просто и быстро.

кроссплатформенного не бывает — везде что-то надо допиливать, или вообще использовать специальные системы сборки (например, на ведроиде).

cmake

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

может есть нечто подобное для cmake? офф гайд какой то мутный

посмотри готовые проекты.

с cmake не разбирался - не подскажу..

autotools во все поля, если сборка не умещается в одну строку (cc -o prog *.c)

Господа, современные autotools очень просты, особенно с non-recursive make

autoscan всё сделает за вас, синтаксис Makefile.am поймёт даже дебил, а libtool позволит забыть про туеву хучу компиляторов и линкеров. И у вас всегда есть возможность воспользоваться грубой силой под названием shell code.

make или qmake, в зависимости от размера и нужна ли портабельность.

cmake — просто и кроссплатформенно.

если действительно нужна кроссплатформенность, то на autotools смотреть даже не надо, ибо это gnu-only поделка.

и как у libtool'а обстоят дела с cl.exe? а еще расскажи как использовать это поделие если в системе нет sh и gmake

для cmake подобное не нужно, ибо hello world тут пишется в две строки

project(hello)
add_executable(hello hello.c)

Используйте cmake.

Я сам пишу либо простые makefile'ы, либо простые mkfile-ы :) Но у меня каких-то диких деревьев исходников нет.

хеллоу вордл это конечно круто, но у меня порядок количества файлов совсем не тот уже. и оно все на msvs делалось

На работе - MsBuild + IncrediBuild, дома - CMake.

ну так перечисляй их все в add_executable

autotools

autotools only

синтаксис Makefile.am поймёт даже дебил

Бааатенька! Мы же о программистах... )))

и как у libtool'а обстоят дела с cl.exe?

Нормально обстоят, говорят.

а еще расскажи как использовать это поделие если в системе нет sh

Поставить sh? 8))

и gmake

Ну с BSD make оно таки работает. С какими-то более другими тоже, типа чпуксовского.

Вообще autocrap былинно гибок, но за пределами unix-like с ним ловить нечего от слова совсем.

Maven. Еще ant хорош. Можно и msbuild/xbuild использовать.

Колотить. gmake не нужен для automake, он генерирует совершенно тупые make-файлы, и грязно ругается, если в Makefile.am есть что-то непортируемое.

Не знаю как CL (common lisp?), но libtool - первую очередь для сборки библиотек из C, C++ и Fortran - в общем, всё, что компилируется. А для остальных языков (perl, python, node.js, etc) есть специализированные средства - и это правильно.

Не знаю как CL (common lisp?)

command line msvc++ =)

Колотить. gmake не нужен для automake

А я что написал? Нет, я понимаю, что читать на лоре не модно изначально, но не до такой же степени.

он генерирует совершенно тупые make-файлы

Которые nmake всё равно не поймёт, ага? Насколько я помню, добавление его поддержки загнулось на этапе обсуждения со словами «nmake на винде — не самая большая проблема с автотулами. Если уж надо ставить sh, sed, awk и тонну всякого — то поставить gmake тем паче не проблема». Напоминаю, что году так в 2001, например, в automake не было поддержки BSD make.

Не знаю как CL (common lisp?), но libtool - первую очередь для сборки библиотек из C, C++ и Fortran - в общем, всё, что компилируется

С чего вдруг cl.exe (не CL, а cl.exe) ВНЕЗАПНО стал лиспом-то?

CMake. И кроссплатформенный, и к гнутому тулчейну не привязан (или я из анабиоза вышел, и autotools тоже не привязаны?).

А под вендами autotools работает со студией?

и как у libtool'а обстоят дела с cl.exe?

Нормально обстоят, говорят.

Нормально, это как? И кто говорит? В MSVC можно будет открыть все это добро сгенерированное из autotools и пользоваться удобствами вроде Visual Assist и запуска под отладчиком?

Дак, Резету много чести отвечать :-)

С чего вдруг cl.exe (не CL, а cl.exe) ВНЕЗАПНО стал лиспом-то?

Вендузятников хрен разберёшь.

./configure CC=/wtf/c/compiler

Вы в MSVC собираетесь писать кроссплатформенный код? o_O

И накой сдались все эти Ассисты? Если вам нужны могучие тулзы для написания кода, то тут два правильных варианта:

1. На самом деле вам нужен кодогенератор (flex, perl, awk, wtf)

2. Вам нужен другой язык.

А что в этом удивительного? Довольно удобно разрабатывать в MSVC, а собирать и тестировать еще под linux. CMake это легко позволяет делать.

Зачем кодогенератор? Плюсового кода уже и так «нагенерировали» очень много, нужно теперь его поддерживать и развивать дальше. «Все эти Ассисты» и удобный отладчик нужны для того, чтобы быстрее разбираться в уже имеющейся куче кода. Без хорошей навигации по коду разбираться придется очень долго. Иметь хорошую документацию по коду тоже неплохо, но она не далеко не всегда имеется в наличии.

Другой язык - не вариант, переписать уже имеющееся будет очень дорого стоить. Да и другие языки не особо подходят на замену C++ в этой области.

два чая этому господину

А разные флаги оно поддерживает? Т.е. то, что для gcc --my-mega-flag, для vs может оказаться /flag-my-mega.

Да, autotools, поди, без mingw не работают?