Многообещающие альтернативы?

проверьте SCons. Например, Doom 3 и Blender используют его.

У меня много друзей, которые клянутся в кроссплатформенной разработке CMake:

http://www.cmake.org/

Это система сборки, используемая для VTK (среди прочего), которая представляет собой библиотеку C++ с кроссплатформенным Python, Привязки Tcl и Java. Я думаю, что это, вероятно, наименее сложная вещь, которую вы найдете с таким количеством возможностей.

Вы всегда можете попробовать стандартные автоинструменты. Файлы Automake довольно легко собрать, если вы работаете только в Unix и придерживаетесь C/C++. Интеграция сложнее, а autotools далеко не самая простая система.

doit — это инструмент Python. Он основан на концепциях инструментов сборки, но более общий.

• вы можете определить, насколько актуальна задача/правило (не только проверка временных меток, целевые файлы не требуются)
• зависимости могут быть вычислены динамически другими задачами
• действия задачи могут быть функциями python или командами оболочки

Некоторые проекты GNOME были перенесены на waf.

Он основан на Python, как и Scons, но также является автономным — поэтому вместо того, чтобы требовать от других разработчиков установки вашего любимого инструмента сборки, вы просто копируете автономный скрипт сборки в свой проект.

Я рекомендую использовать Rake. Это самый простой инструмент, который я нашел.

Другие хорошие инструменты, которые я использовал, если вам не нравится Ruby, это:

• AAP (Python)
• SCons (Python)
• Ant (Java, конфигурация в XML, довольно сложная)

Обратите внимание на инструмент сборки ninja (версия 1.8.2, сентябрь 2017 г.), на который повлиял tup и redo< /а>.

Генератор файлов сборки cmake (например, для Unix Makefiles, Visual Studio, XCode, Eclipse CDT, ...) также может генерировать ninja файлы сборки, начиная с версии 2.8.8 (апрель 2012 г.), и, по правде говоря, ninja теперь даже является инструментом сборки по умолчанию, используемым cmake.

Предполагается, что он превосходит инструмент make (лучшее отслеживание зависимостей, а также параллелизм).

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

Обратите внимание, что время компиляции улучшения c/c++ иногда ограничено из-за заголовков, включенных через препроцессор (в частности, при использовании библиотек только для заголовков, например boost и eigen), которые, как мы надеемся, будут заменены предложением модули (в техническом обзоре С++ 11 или, в конечном итоге, С++ 1y). Ознакомьтесь с этой презентацией. для получения подробной информации по этому вопросу.

Я написал инструмент под названием sake, который пытался сделать написание подобных make-файлов очень простым для чтения и написания.

Это зависит от того, что вы пытаетесь сделать. Если вам все нужны целевые зависимости в стиле make и вызов команд, то Make на самом деле является одним из лучших инструментов для этой задачи. :-) Rake очень хорош, но может быть неуклюжим для некоторых простых случаев. Ant, конечно, город многословия, но он лучше поддерживает создание Java-подобных языков (включая Scala и Groovy). Кроме того, Ant доступен везде. Это основная причина, по которой я его использую. Поскольку он стабильно работает в Windows, на самом деле он даже более кроссплатформенный, чем Make.

Если вам нужно управление зависимостями для Java-подобных библиотек, каноническим выбором будет Maven, но лично мне Buildr нравится намного больше. Его быстрее и намного проще настроить (он основан на Rake). К сожалению, пока он не так распространен, как Maven.

Я все еще предпочитаю make после рассмотрения множества альтернатив. Когда вы автоматически генерируете зависимости через компилятор или что-то вроде fastdep, остается не так много. В частности, я не хочу, чтобы мой сценарий сборки был привязан к языку реализации, и мне не нравится писать что-то в XML, когда доступны более читаемые альтернативы. Инструмент, раскрывающий язык общего назначения, заслуживает внимания, а другой интерпретируемый язык — нет (афаик). Что не так с Make? может понравиться вашей точке зрения на отходит от make.

/Аллан

Система make в Ruby называется rake: http://rake.rubyforge.org/

Выглядит весьма многообещающе.

Всегда есть Ant: http://ant.apache.org, который я лично нахожу ужасным. Однако это стандарт де-факто для разработки на Java.

FlowTracer от RTDA — еще один хороший выбор, который я видел в коммерческих целях в крупномасштабной среде (десятки тысяч рабочих мест): http://www.rtda.com/flowtracer-design-flow-infrastructure-software

Он имеет графический интерфейс, который показывает график зависимостей с цветными прямоугольниками для заданий и овалами для файлов. Когда количество заданий и файлов становится большим, инструмент с графическим интерфейсом, такой как FlowTracer, очень важен.

Первоначальная стоимость установки выше, чем у Make. Существует кривая обучения для настройки вашего первого потока с его использованием. После этого становится быстрее.

Я не уверен, что вы задаете здесь правильный вопрос.

Вы после упрощенной сделать? В этом случае вам нужно попросить кого-нибудь, хорошо знакомого с make, создать серию (M|m)akefile, которые упростят вашу проблему.

Или вы хотите посмотреть на базовую технологию? Хотим ли мы внедрить архитектуру типа «проектирование по контракту», которая встроена в дизайн кода и применяется в нем? Или, возможно, сам язык, например. Ада и ее концепция спецификаций (интерфейсов) и тел (реализации)?

Какое направление вы после определенно повлияет на потенциальные результаты такого вопроса?

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

Извините, это не прямой ответ. Просто хотел попытаться заставить вас оценить, по какому пути вы хотите пойти.

ваше здоровье,

Роб