В настоящее время самая лучшая система сборки

Несколько лет назад я изучил использование некоторой системы сборки, которая не является Make, а инструменты вроде CMake и SCons казались довольно примитивными. Я хотел бы узнать, улучшилась ли ситуация. Итак, по следующим критериям, в настоящее время лучший инструмент построения:

агностик платформы: должен работать на windows, linux, mac
language agnostic: должен иметь встроенную поддержку общих вещей, таких как построение C/С++ и других статических langs. Думаю, ему не нужно поддерживать полный комплект автозагрузки.
extensible: мне нужно писать правила для создания файлов, например, из реструктурированного текста, латекса, пользовательских форматов и т.д. Мне не важно, на каком языке я должен писать правила, но я предпочел бы настоящий язык, а чем DSL.
Я бы предпочел не писать любой XML вручную, что, на мой взгляд, требует ant.
Свободно доступный (предпочтительно с открытым исходным кодом)

Термин "лучший" слегка субъективен, но я думаю, что ответы могут быть объективно оценены по вышеуказанным критериям.

Ответ 1

Я окончательно поставил бы свой голос за premake. Хотя это не так сильно, как старшие братья, главное преимущество - абсурдная простота и простота использования. Делает запись многокомпилирующего компилятора, многоплатформенного кода ветерок, и изначально генерирует решения Visual Studio, проекты XCode, Makefiles и другие, без какой-либо дополнительной работы.

Ответ 2

Итак, судя по критериям, изложенным в вопросе, система сборки, которая кажется наилучшим образом подходит, вероятно, waf - чистый Python, обеспечивает поддержку С++ и других языков, общий, мощный, а не DSL.

Однако из моего личного опыта я предпочитаю проекты CMake для С++. (Я попробовал CMake, SCons и waf, и понравился им примерно в таком порядке). CMake - общее решение, но у него есть встроенная поддержка С++, которая делает его более приятным, чем более общее решение, когда вы на самом деле выполняете С++.

Модель сборки CMake для С++ более декларативная и менее настоятельная, и, следовательно, для меня это проще в использовании. Синтаксис языка CMake невелик, но декларативная сборка с нечетным синтаксисом превосходит обязательную сборку в Python. Из трех, CMake также, похоже, имеет лучшую поддержку "продвинутых" вещей, таких как предварительно скомпилированные заголовки. Настройка предварительно скомпилированных заголовков сократила время восстановления примерно на 70%.

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

Часть проблемы, которую я обнаружил при экспериментировании с системами сборки, заключается в том, что я пытался создать плагин NPAPI для OS X, и оказалось, что очень мало систем сборки настроены так, чтобы дать XCode точную комбинацию флагов, необходимых для Сделай так. CMake, признавая, что XCode является сложной и движущейся целью, обеспечивает крючок для ручной настройки команд в сгенерированных проектах XCode (и, я думаю, Visual Studio). Это очень умно, насколько мне известно.

Если вы создаете библиотеку или приложение, вы также можете определить, какая система сборки лучше. Boost по-прежнему использует систему на основе Jam, отчасти потому, что она обеспечивает самую полную поддержку для управления типами сборки, которые сложнее, чем "Debug" и "Release". Большинство ускорительных библиотек имеют пять или шесть разных версий, особенно в Windows, предвосхищая людей, которым нужны совместимые библиотеки, которые связаны с различными версиями ЭЛТ.

У меня не было никаких проблем с CMake в Windows, но, конечно, ваш пробег может отличаться. Там есть достойный графический интерфейс для настройки зависимостей сборки, хотя он неуклюже используется для перестроек. К счастью, есть и клиент командной строки. До сих пор я решил иметь тонкую оболочку Makefile, которая вызывает CMake из objdir; Затем CMake генерирует Makefiles в objdir, а исходный Makefile использует их для выполнения сборки. Это гарантирует, что люди не случайно ссылаются на CMake из исходного каталога и загромождают свой репозиторий. В сочетании с MinGW этот "сэндвич CMake" обеспечивает замечательную совместимость с кросс-платформенным построением!

Ответ 3

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

Один - tup:

http://gittup.org/tup/

а другой изготовлен:

http://code.google.com/p/fabricate/

Тот, который, кажется, самый эффективный, портативный и зрелый (и тот, который я фактически использовал), является tup. Парень, который написал его, даже поддерживает игрушечный дистрибутив linux, где все это подмодуль git, и все (включая ядро) построено с помощью tup. Из того, что я прочитал о системе сборки ядра, это довольно успешное решение.

Кроме того, Tup очищает старые цели и другие трещины и может автоматически поддерживать ваши файлы .gitignore. В результате становится тривиальным экспериментировать с макетом и именами ваших целей, и вы можете уверенно прыгать между версиями git без восстановления всего. Это написано на C.

Если вы знаете, что haskell и ищете что-то для очень продвинутых вариантов использования, проверьте дрожь:

http://community.haskell.org/~ndm/shake/

Обновление: я не пробовал, но этот новый "встроенный" инструмент также подключается к файловой системе и вдохновлен tup, поэтому имеет значение:

https://github.com/ElastiLotem/buildsome

Ответ 4

CMake

CMake является расширяемым открытым исходным кодом система, которая управляет процессом сборки в операционной системе и в независимый от компилятора.

Ответ 5

Gradle, похоже, соответствует всем указанным выше критериям.

Это система сборки, которая взяла лучшее из Maven и Ant в сочетании. Для меня это лучший.

Ответ 6

Проект Selenium переходит на Rake, а не потому, что он лучший, а потому, что он обрабатывает несколько языков немного лучше, чем все другие инструменты для сборки и являются кросс-платформенными (разработанными в Ruby).

Все инструменты сборки имеют свои проблемы, и люди учатся жить с ними. Что-то, что работает на JVM, как правило, очень полезно для создания приложений, поэтому Ant, Maven (я знаю его отвратительный), Ivy, Rake

Ответ 7

Final Builder хорошо известен в мире Windows

Ответ 8

плавная сборка соответствует большинству ваших требований.

агностика платформы: да, она написана в java
language agnostic: он еще не поддерживает c/С++ t, только java, но он расширяем через плагины, написанные в java, поэтому добавление дополнительной поддержки компиляторов не является проблемой.
extensible: да, вы можете реализовать плавную функцию через плагин java, вы также можете создавать плавную функцию, определяя ее как выражение, построенное из других гладких функций.
Я бы предпочел не писать любой XML: вы не увидите ни одной строки в плавной структуре
Свободно доступный: да, лицензия Apache 2

раскрытие: Я автор гладкой сборки.