Прямое использование Make считается устаревшим? [закрыто]

Поэтому я сталкивался со многими комментариями / публикациями / и т. Д., Касающимися непосредственного создания make-файлов, и того, как это глупо делать в 2015 году. Мне известны такие инструменты, как CMake, и я на самом деле довольно часто использую CMake. Дело в том, что CMake просто создает Makefile для вас и помогает избавиться от скуки делать это самостоятельно. Конечно, он добавляет много других замечательных функций ... но в конце концов это все еще Makefile.

Поэтому мой вопрос заключается в том, является ли «устаревшим» разговор о make со ссылкой на всю утилиту Make или просто идея ручного написания ваших собственных Makefile? Я вообще не использую IDE для разработки на C / C ++ (просто emacs), поэтому я всегда писал Makefiles.

Если Make считается устаревшим, что разработчик C / C ++ должен использовать для создания небольших личных проектов?

Большая разница в том, что CMake - это кроссплатформенная система мета-сборки. Один проект CMake может создать обычный make-файл для Unix / Linux, проект Visual Studio для Windows, проект XCode для Mac и почти любую другую не-метаданную систему сборки, которую вы можете использовать или поддерживать.

Я бы не сказал, что использование make напрямую или даже ручное редактирование make-файлов «устарело», но это то, что вы, вероятно, не должны делать, если вы не работаете над Unix / Linux, который не нуждается в портировании на Windows, так же, как вы не следует редактировать файлы проекта Visual Studio напрямую, если вы когда-нибудь захотите перенести их в не-Windows. Если у вас есть интерес к переносимости, стоит изучить систему мета-сборки, такую ​​как Scons или CMake.

Это makeдействительно устарело?

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

Но то, что сырье makeне предоставляет, - это расширенные функциональные возможности и стандартные библиотеки для удобства, такие как параметрическое создание заголовков, интегрированная среда тестирования или даже просто условные библиотеки в целом.

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

Учитывая, что вы можете создать в C ++ гораздо больше, чем просто обычное приложение для системы, которая знает загрузчики ELF, CMakeконечно, не подходит для всех сценариев. Однако, если вы работаете в такой стандартизированной среде CMakeили любой другой из этих современных сред генератора сценариев, безусловно, ваши лучшие друзья.

Это всегда зависит от того, насколько специализировано ваше приложение и насколько хорошо структура CMakeфреймворка соответствует вашему рабочему процессу.

Когда-то языки высокого уровня были просто идеей. Люди пытались реализовать компиляторы. В то время существовали жесткие аппаратные ограничения - не было графических инструментов, поэтому в качестве формата входного файла использовался «простой текст»; на компьютерах обычно было очень мало оперативной памяти, поэтому исходный код приходилось разбивать на части, а компилятор разделялся на отдельные утилиты (препроцессор, компилятор, ассемблер, компоновщик); Процессоры были медленными и дорогими, поэтому вы не могли выполнять дорогостоящие оптимизации и т. Д.

Конечно, со многими исходными файлами и множеством утилит, используемых для создания множества объектных файлов, создавать что-либо вручную - беспорядок. В качестве обходного пути для недостатков дизайна в инструментах (вызванных сильно ограниченным аппаратным обеспечением) люди, естественно, начали писать сценарии для устранения некоторых проблем.

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

Тем не мение; Makefiles неуклюжи и грязны. Чтобы обойти проблемы с make-файлами (которые были обходным путем для устранения недостатков проектирования в инструментах, вызванных ограниченным оборудованием), люди начали экспериментировать с автоматически генерируемыми make-файлами; начиная с таких вещей, как получение компилятором для генерации зависимостей; и приводит к таким инструментам, как auto-conf и cmake.

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

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

make (инструмент или прямое использование его через Makefile) не устарел, особенно для «небольших, личных проектов», для которых вы его используете.

Конечно, вы также можете использовать его для более крупных проектов, в том числе для нескольких платформ. С помощью переменных, специфичных для целей, вы можете легко настроить способ сборки для разных платформ. В настоящее время дистрибутивы Linux поставляются с кросс-компиляцией наборов инструментов (например, mingw-w64 ), так что вы можете создать полный пакет программного обеспечения Windows (с программой установки, если вам нравится) из Linux, все из которых создаются из вашего Makefile.

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

IDE, такие как Qt Creator и Eclipse, также могут импортировать проекты на основе Makefile, чтобы вы могли делиться ими с разработчиками, использующими IDE. Я думаю, что Qt Creator IDE превосходна в качестве C ++ IDE, но, потратив некоторое время, чтобы стать более эффективным с Emacs, и, поскольку я больше занимаюсь разработкой Ada, я предпочитаю Emacs для всего. Чтобы вернуться к вопросу о том make, что как шаг после ссылки в моем Makefile, я обновляю свой файл TAGS (для навигации по символам в Emacs), загруженный M-x visit-tags-table:

find $(SRC_DIR) $(TEST_DIR) -regex ".*\.[ch]\(pp\)?" -print | etags -

Или для развития Ады:

find $(SRC_DIR) $(TEST_DIR) -name "*.ad?" -print | etags -

Этот ответ дополняет ответ @lxrec.

Makefiles можно использовать для многих целей, а не просто для создания программы / библиотеки из исходного кода. Системы сборки, такие как CMake или autotools, предназначены для получения кода и его сборки таким образом, чтобы он подходил для платформы пользователя (т.е. находил библиотеки или определял правильные параметры компиляции). Например, у вас может быть make-файл, который помогает автоматизировать некоторые задачи выпуска, такие как: создать zip-файл, содержащий код с версией, полученной из git; запускать тесты против вашего кода; загрузить указанный zip-файл на какой-либо хостинг. Некоторые системы сборки (например, automake) могут обеспечить простой способ сделать это, другие - нет.

Это не значит, что для этого вам нужно использовать make-файлы, вы можете использовать язык сценариев (shell, python и т. Д.) Для таких задач.

Я не думаю, что написанное человеком Makefileустарело, особенно когда:

1. используя POSIX make, который дает вам портативный Makefile
2. или используя GNU make 4, который дает вам много очень интересных функций, в частности, возможность написания сценариев GUILE, который позволяет эффективно кодировать необычные функции, предоставляемые Makefileгенераторами (я считаю, что функции автоинструментов или Cmake можно было бы легко написать с помощью настройки Guile в GNU make ). Конечно, цена, которую нужно заплатить, - это потребовать, чтобы GNU составлял 4 (не имеет большого значения, имхо).

Make-файлы не являются устаревшими, так же как текстовые файлы не являются устаревшими. Хранение всех данных в виде простого текста не всегда является правильным способом выполнения действий, но если все, что вам нужно, это список Todo, то файл в виде простого текста подойдет. Для чего-то более сложного вам может потребоваться более сложный формат, такой как Markdown или XML, или пользовательский двоичный формат, или что-то среднее, но в простых случаях обычный текст работает нормально.

Точно так же, если все, что вам нужно, - это способ не писать g++ -g src/*.c -o blah -W -Wall -Werror && ./blahвсе время, рукописный Makefile идеален!

Если вы хотите создать что-то с высокой степенью переносимости, когда вам не нужно управлять этой переносимостью самостоятельно, вы, вероятно, захотите, чтобы что-то вроде Autotools сгенерировало подходящий Makefile для вас. Автоинструменты будут определять функции, поддерживаемые различными платформами. Программа, написанная на стандартном C89, построенная с помощью Autotools, будет компилироваться практически везде.

если ваш проект прост и содержит очень мало файлов, то файл make не требуется.

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

Если вы хотите стереть старые файлы / compile / link / install с минимальным количеством хлопот и вероятностью ошибок нажатия клавиш, make-файл - это настоящее благо.

Когда вы попадаете в проекты «реального мира», редко бывает всего 1 или 2 файла, а скорее сотни файлов. make-файл всегда будет выполнять правильные действия, а не ненужные (после отладки), поэтому вы вводите только одну простую команду, а make-файл выполняет всю работу.