Перспективные альтернативы сделать?
Я использую make и makefiles уже много лет, и хотя эта концепция является разумной, в реализации есть что-то, что можно пожелать.
Кто-нибудь нашел хорошие альтернативы, которые не усложняют проблему?
12 ответов
У меня много друзей, которые клянутся CMake за кроссплатформенную разработку:
Это система сборки, используемая для VTK (среди прочего), который представляет собой библиотеку C++ с кроссплатформенными привязками Python, Tcl и Java. Я думаю, что это, вероятно, наименее сложная вещь, которую вы найдете с таким количеством возможностей.
Вы всегда можете попробовать стандартные автоинструменты. Файлы Automake довольно легко собрать, если вы работаете только в Unix и придерживаетесь C/C++. Интеграция более сложна, и автоинструменты далеки от самой простой системы.
doit - инструмент для Python. Он основан на концепциях инструментов сборки, но более универсален.
- вы можете определить, насколько актуальна задача / правило (не только проверка временных меток, целевые файлы не требуются)
- зависимости могут быть рассчитаны динамически другими задачами
- действиями задачи могут быть функции python или команды оболочки
Некоторые из проектов GNOME были переведены на waf.
Он основан на Python, как Scons, но также и автономен - поэтому вместо того, чтобы требовать от других разработчиков установки вашего любимого инструмента сборки, вы просто копируете автономный скрипт сборки в свой проект.
Знать о 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), которые, мы надеемся, будут заменены предложением модулей (в техническом обзоре с ++11 или в конце концов с ++1y). Проверьте эту презентацию для деталей по этому вопросу.
Я написал инструмент под названием sake, который пытался сделать записи, похожие на makefile, очень удобными для чтения и записи.
Это зависит от того, что вы пытаетесь сделать. Если вам нужны только целевые зависимости в стиле make и вызов команды, то Make на самом деле является одним из лучших инструментов для этой задачи.:-) Рейк очень хорош, но может быть неуклюжим для некоторых простых случаев. Ant, конечно, многословный город, но он лучше поддерживает создание Java-подобных языков (включая Scala и Groovy). Также Ant доступен везде. Это главная причина, по которой я его использую. Поскольку он работает последовательно в Windows, он на самом деле даже более кроссплатформенный, чем Make.
Если вам нужно управление зависимостями для Java-подобных библиотек, Maven - канонический выбор, но лично мне Buildr намного лучше. Это быстрее и намного проще в настройке (он основан на Rake). К сожалению, он пока не такой повсеместный, как Maven.
Я все еще предпочитаю делать после рассмотрения множества альтернатив. Когда вы автоматически генерируете зависимости через компилятор или что-то вроде fastdep, вам мало что остается делать. В частности, я не хочу, чтобы мой скрипт сборки был привязан к языку реализации, и я не люблю писать вещи в XML, когда доступны более читаемые альтернативы. Инструмент, который раскрывает язык общего назначения, имеет свои достоинства, но еще один интерпретируемый язык - нет (afaik). Что не так с маркой? может обратиться к вашей точке зрения об уходе от make.
/ Allan
Система Ruby's make называется 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)akefiles, которая упростит вашу проблему.
Или вы хотите взглянуть на основную технологию? Мы хотим внедрить архитектуру типа "дизайн за контрактом", которая встроена в кодовый дизайн? Или, возможно, сам язык, например, Ada и его концепция спецификаций (интерфейсов) и тел (реализаций)?
В каком направлении вы будете следовать, определенно повлияет на потенциальные результаты такого вопроса?
По сути, новые способы построения систем только из тех компонентов, которые действительно изменились, по сравнению с принятием новых технологий, в которых такие механизмы встроены в конструкцию.
Извините, это не прямой ответ. Просто хотел попытаться заставить вас оценить, по какому пути вы хотели идти.
веселит,
обкрадывать