CMake 3.0

Это такой make, только не make и с поломанной обратной совместимостью со старым не-make?

не нужно. autotools - наше все!

нет. это как ./configure.

Это кроссплатформенная замена autocrap.

goodies

Расширен язык и синтаксис CMake.

ну хоть бы маленький пример дал бы

Новые переменные Kate и CodeLite, доступны для использования в Makefile.

не распарсил

A new CodeLite extra generator is available for use with the Makefile or Ninja generators.
A new Kate extra generator is available for use with the Makefile or Ninja generators.
The Ninja generator learned to use ninja job pools when specified by a new JOB_POOLS global property.

the end.

да, я уже перешел по ссылке. теперь интересно под чем автор переводил :)

Promt'98, локализация от Фаргуса

перевод страдает, сорри :'(

Ждём ебилдов.

autotools закопать пора

autotools закопать пора

Согласен. Но в конце такого утверждения нужно ставить 3 (три) восклицательных знака.

Список поддерижваемых платформ несравним. Для какого-нибудь древнекоммерческого Unix-а кроме autotools ничего нет.

Список поддерижваемых платформ несравним.

Но зато CMake хорош, очень хорош.

Список поддерижваемых платформ несравним

90% из которых мертвы, а вот с распространенными платформами у autotools жопа полная.

не нужно. autotools - наше все!

+1

autotools закопать пора

они ещё тебя переживут наверняка

autotools - де-факто стандарт для систем сборки всего свободного ПО

И это крайне прискорбно.

Это скорее историческое наследие. В относительно новых проектах его нет.

Еще бы они заменили свой наркоманский DSL язык на что-то более общепринятое: JavaScript, Python, Ruby, Perl, Lua в конце-концов и цены бы ему не было.

QBS - то что надо, а вот cmake - кака

autotools - де-факто стандарт для систем сборки всего свободного ПО

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

Насколько оно уже юзабельно?

ППКС

Из чего следует, что ни один из них пока выбрасывать не стоит.

не нужно. autotools - наше все!

++

Список поддерижваемых платформ несравним. Для какого-нибудь древнекоммерческого Unix-а кроме autotools ничего нет.

Ну, почему же. Вот вам алгоритм сравнения:

Сравни количество денег, которые готов заплатить владелец того самого Unix'а с количеством усилий, которые нужно приложить для его полноценной поддержки.

не нужно. autotools - наше все!

+1

QBS - то что надо, а вот cmake - кака

Глупости. Они абсолютно разные, QBS - не генератор, а часто именно это и требуется.

Cmake убог, но лучшее, что есть (для всяких там плюсов).

Во-во, DSL у cmake блевотный, могли бы ведь сделать какой-нибудь нормальный декларативный с escape hatch'ами в императивность на базе чего-нибудь вменяемого, но нет :-(

Уж лучше autotools, чем ЭТО, как по мне, если только Windows не нужен...

Поддерживаю комплексующих по поводу языка CMake. Не вижу причин, почему его нельзя заменить на тот же Python, JS или Lua. Разработчики видно сильно озабочены обратной совместимостью с существующим кодом, иначе рискуют потерять пользователей. Это их и погубит, отсутствие развития похоронило многие проекты. Сейчас вон свежая кровь подоспела в виде QBS, но последний до сих пор в состоянии студенческой поделки.

Не нужно, для Ъ есть autotools, для просветленных — plain make-файлы, для ценителей — premake

Вот autotools как раз надо закопать.

autotools - де-факто стандарт для систем сборки всего свободного ПО

Таблетки выпить забыл?

я-то выпил, а ты, кажется, отрицаешь объективную реальность :)

Неосиляторы autotools доставляют, там всего-то надо 3 мануала прочитать вдумчиво, и всё сразу легко и понятно станет

минусы autotools, перечисляй

CMake потихоньку, но развивается, вот сильно улучшили поддержку Ninja в 3.0. А когда добавят тот же Ninja в autotools? Я уже не говорю про элементарные вещи, вроде отдельной директории сборки вместо того, чтобы гадить обьектниками прямо в исходники. Или вспомним про степень поддержки autotools на Windows.

• Тормознутось - система построена на shell скриптах
• Куча мусора в выводе - см. п. 1 3
• Огромный автосгенерированный скрипт в дистрибутиве
• Убогий и неочевидный синтаксис (хотя и CMake не идеал, но там синтаксис лучше)
• Куча оверхеда даже для простых случаев

Ну и до кучи: http://voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/

Теневая сборка в autotools вроде бы есть, но работает не всегда.

Да сколько мажорных версий можно-то! Они что — сговорились?

Ну дык RedHat Linux 7 зарелизился на днях, вот и перестали искусственно сдерживать.

Теневая сборка в autotools вроде бы есть, но работает не всегда.

Найдите мне хоть один проект на autotools в Git, в котором отсутствует .gitignore. Их авторы соревнования могут устраивать по степени упоротости игнорируемых паттернов.

Я ни в коем случае не оправдываю autotools, я лишь написал что теневая сборка с autotools возможна. Упоротость .gitignore в autotools проектах говорит скорее всего о том, что теневая сборка применяется чуть чаще чем никогда.

autotools закопать пора

Хрен редьки не слаще.

Но зато CMake хорош, очень хорош.

С каким ключом бинари в CMake собираются статически?

Найдите мне хоть один проект на autotools в Git, в котором отсутствует .gitignore.

Внезапно, .gitignore нужен даже если проект не использует ни аутотолс, ни цмаке. Мусор генерируемый в каталогах файловыми менеджерами для индексации каталогов тоже предлагаешь ставить под версионный контроль и собирать со всех операционок?

Мусор генерируемый в каталогах файловыми менеджерами для индексации каталогов тоже предлагаешь ставить под версионный контроль и собирать со всех операционок?

Проблемы мусорных файлменеджеров. Файлы должны создаваться исключительно по желанию пользователя. Для ССЗБ есть глобальный .gitignore или локальный .git/info/exclude. Типичная же свалка в .gitignore проектов на autotools к этому отношения не имеет.