Перспективные альтернативы? [закрыто]

Я использую make и make-файлы в течение многих лет, и, хотя концепция разумна, в реализации есть что-то желаемое.

Кто-нибудь нашел хорошие альтернативы, которые не усложняют проблему?

проверьте 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инструменте сборки (v1.8.2, сентябрь 2017 г.), на который влияют tupи redo.

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

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

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

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

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

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

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

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

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

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

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

/ Аллан

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

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

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

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

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

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

В каком направлении вы будете двигаться, это определенно повлияет на потенциальные результаты такого вопроса?

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

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

ура,

Роб