Многообещающие альтернативы?[закрыто]
https://stackoverflow.com/questions/66800
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я использую Make and Makefiles в течение многих лет, и хотя концепция звучит, у реализации есть что -то, что нужно.
Кто -нибудь нашел какие -либо хорошие альтернативы, которые не преувеличивают проблему?
Решение
проверить SCons.Например, Doom 3 и Blender используют его.
Другие советы
У меня много друзей, которые доверяют CMake в плане кроссплатформенной разработки:
Это система сборки, используемая для ВТК (помимо прочего), которая представляет собой библиотеку C++ с кроссплатформенными привязками Python, Tcl и Java.Я думаю, что это, вероятно, наименее сложная вещь, которую вы найдете с таким количеством возможностей.
Вы всегда можете попробовать стандартный автоинструменты.Файлы Automake довольно легко собрать, если вы работаете только в Unix и придерживаетесь C/C++.Интеграция сложнее, а autotools — далеко не самая простая система.
Некоторые проекты GNOME перешли на ваф.
Он основан на Python, как и Scons, но при этом является автономным — поэтому вместо того, чтобы требовать от других разработчиков установки вашего любимого инструмента сборки, вы просто копируете автономный сценарий сборки в свой проект.
сделай это это инструмент Python.Он основан на концепциях инструментов сборки, но более общий.
- вы можете определить, насколько актуальна задача/правило (не только проверка меток времени, целевые файлы не требуются)
- зависимости могут рассчитываться динамически другими задачами
- действия задачи могут быть функциями Python или командами оболочки.
Имейте в виду ninja инструмент сборки (v1.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++ время компиляции иногда ограничено из-за заголовков, включенных через препроцессор (в частности, при использовании библиотек только с заголовками, например) способствовать росту & собственный), которое, как мы надеемся, будет заменено предложением модули (в техническом обзоре C++11 или, в конечном итоге, в C++1y).Проверьте это презентация для получения подробной информации по этому вопросу.
Я написал инструмент под названием ради который пытался сделать написание 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/
Выглядит весьма многообещающе.
Всегда есть Муравей: http://ant.apache.org, что лично мне кажется ужасным.Однако это стандарт де-факто для разработки на Java.
Я не уверен, что вы задаете здесь правильный вопрос.
Вы предпочитаете упрощенную версию?В этом случае вам нужно попросить кого-нибудь, кто хорошо знаком с make, создать серию (M|m)ake-файлов, которые упростят вашу проблему.
Или вы хотите взглянуть на лежащую в основе технологию?Хотим ли мы внедрить архитектуру типа «проектирование по контракту», которая встроена и применяется в дизайне кода?Или, возможно, сам язык, например.Ада и ее концепция спецификаций (интерфейсов) и тел (реализаций)?
Какое направление вы выбираете, обязательно повлияет на потенциальные результаты такого вопроса?
По сути, новые способы построения систем только из тех компонентов, которые действительно изменились, по сравнению с внедрением новых технологий, в которых такие механизмы встроены в дизайн.
Извините, это не прямой ответ.Просто хотел попытаться заставить вас оценить, по какому пути вы хотите идти.
ваше здоровье,
Роб
FlowTracer от RTDA — еще один хороший выбор, который я видел в коммерческих целях в крупномасштабной среде (десятки тысяч рабочих мест): http://www.rtda.com/flowtracer-design-flow-infrastructure-software
Он имеет графический интерфейс, который показывает график зависимостей с цветными полями для заданий и овалами для файлов.Когда количество заданий и файлов становится большим, инструмент с графическим интерфейсом, такой как FlowTracer, становится очень важным.
Стоимость первоначальной установки выше, чем у Make.Существует кривая обучения для настройки вашего первого потока с его использованием.После этого дело пойдет быстрее.
