Поэтому я сталкивался со многими комментариями / публикациями / и т. Д., Касающимися непосредственного создания make-файлов, и того, как это глупо делать в 2015 году. Мне известны такие инструменты, как CMake, и я на самом деле довольно часто использую CMake. Дело в том, что CMake просто создает Makefile для вас и помогает избавиться от скуки делать это самостоятельно. Конечно, он добавляет много других замечательных функций ... но в конце концов это все еще Makefile.
Поэтому мой вопрос заключается в том, является ли «устаревшим» разговор о make со ссылкой на всю утилиту Make или просто идея ручного написания ваших собственных Makefile? Я вообще не использую IDE для разработки на C / C ++ (просто emacs), поэтому я всегда писал Makefiles.
Если Make считается устаревшим, что разработчик C / C ++ должен использовать для создания небольших личных проектов?
make
без Makefile. В чем суета?make
были впервые написаны, они не должны ожидать, что люди обойдут это.CMake
это слой абстракции. Эта абстракция необходима, чтобы укротить дикое разнообразие потребительских IDE-продуктов, которые не соответствуют open-sourceMakefile
. Опять же, это не только абстракция, но и возможность конфигурации (например, autoconf). Как и другие абстракции, он допускает альтернативы . Но это прокладывает путь экспериментальной новой идеи альтернативы Makefile, легко доступной пользователям CMake.Ответы:
Большая разница в том, что CMake - это кроссплатформенная система мета-сборки. Один проект CMake может создать обычный make-файл для Unix / Linux, проект Visual Studio для Windows, проект XCode для Mac и почти любую другую не-метаданную систему сборки, которую вы можете использовать или поддерживать.
Я бы не сказал, что использование make напрямую или даже ручное редактирование make-файлов «устарело», но это то, что вы, вероятно, не должны делать, если вы не работаете над Unix / Linux, который не нуждается в портировании на Windows, так же, как вы не следует редактировать файлы проекта Visual Studio напрямую, если вы когда-нибудь захотите перенести их в не-Windows. Если у вас есть интерес к переносимости, стоит изучить систему мета-сборки, такую как Scons или CMake.
источник
make
также кроссплатформенный.-lm
,-lnsl
и так далее, или же эти средства включены в библиотеку C и т. д.).CMake
, что он в основном предназначен для создания стандартного модульного приложения для систем с загрузчиками ELF и предоставляет абстракции для всех инструментов, необходимых для этой конкретной цепочки инструментов. Если вы отойдете от этой цепочки инструментов (например, пользовательский скрипт компоновщика для «голого металла»),CMake
вдруг не предоставите никакой поддержки или переносимости, вы в конечном итоге будете его взламывать точно так же, как вы использовали для взлома полностью пользовательских сценариев сборки.Это
make
действительно устарело?Я так не думаю. В конце концов, make все еще достаточно мощный, чтобы обеспечить всю желаемую функциональность, такую как условная компиляция измененного исходного кода и тому подобное. Утверждение
make
было устаревшим, было бы то же самое, что сказать, что написание пользовательских сценариев компоновщика было устаревшим.Но то, что сырье
make
не предоставляет, - это расширенные функциональные возможности и стандартные библиотеки для удобства, такие как параметрическое создание заголовков, интегрированная среда тестирования или даже просто условные библиотеки в целом.С другой стороны,
CMake
непосредственно ориентирован на создание общих библиотек ELF и исполняемых файлов. Всякий раз, когда вы отказываетесь от этих предопределенных процедур, вы должны начинать взломать такCMake
же, как вы использовали для взлома свои собственные Makefiles.Учитывая, что вы можете создать в C ++ гораздо больше, чем просто обычное приложение для системы, которая знает загрузчики ELF,
CMake
конечно, не подходит для всех сценариев. Однако, если вы работаете в такой стандартизированной средеCMake
или любой другой из этих современных сред генератора сценариев, безусловно, ваши лучшие друзья.Это всегда зависит от того, насколько специализировано ваше приложение и насколько хорошо структура
CMake
фреймворка соответствует вашему рабочему процессу.источник
Когда-то языки высокого уровня были просто идеей. Люди пытались реализовать компиляторы. В то время существовали жесткие аппаратные ограничения - не было графических инструментов, поэтому в качестве формата входного файла использовался «простой текст»; на компьютерах обычно было очень мало оперативной памяти, поэтому исходный код приходилось разбивать на части, а компилятор разделялся на отдельные утилиты (препроцессор, компилятор, ассемблер, компоновщик); Процессоры были медленными и дорогими, поэтому вы не могли выполнять дорогостоящие оптимизации и т. Д.
Конечно, со многими исходными файлами и множеством утилит, используемых для создания множества объектных файлов, создавать что-либо вручную - беспорядок. В качестве обходного пути для недостатков дизайна в инструментах (вызванных сильно ограниченным аппаратным обеспечением) люди, естественно, начали писать сценарии для устранения некоторых проблем.
К сожалению, сценарии были неуклюжими и грязными. Чтобы обойти проблемы со сценариями (которые обходили недостатки дизайна в инструментах, вызванные ограниченным аппаратным обеспечением), в конечном итоге люди изобрели утилиты, чтобы упростить задачу
make
.Тем не мение; Makefiles неуклюжи и грязны. Чтобы обойти проблемы с make-файлами (которые были обходным путем для устранения недостатков проектирования в инструментах, вызванных ограниченным оборудованием), люди начали экспериментировать с автоматически генерируемыми make-файлами; начиная с таких вещей, как получение компилятором для генерации зависимостей; и приводит к таким инструментам, как auto-conf и cmake.
Вот где мы сейчас находимся: обходные пути для обходных путей для обходного пути для конструктивных недостатков инструментов, вызванных ограниченным аппаратным обеспечением.
Я ожидаю, что к концу столетия на существующей куче будет еще несколько слоев «обходных путей». По иронии судьбы, серьезные аппаратные ограничения, которые вызвали все это, исчезли много десятилетий назад, и единственная причина, по которой мы до сих пор используем такой архаичный беспорядок, заключается в том, что «так было всегда ».
источник
cmake
только лечение симптомов и не могут вылечить основную причину (ы); что облегчает принятие факта, что у вас нет другого выбора, кроме как использовать инструменты, которые, вероятно, никогда не будут близки к «идеальным».make
в основе их лежит движок для ациклического графа зависимостей. Ничто о «сценариях» или командной строке не является «архаичным».#include
является ребром, ноmake
не может анализировать C-файлы. Все еще не проблема, потому чтоmake
может хранить эти ребра со следующим узлом (файл * .o), но это также не делает этого.make
не только для компиляции C! Вы хотите программу, которая берет.c
и.h
файлы и даетMakefile
с. Но это не такmake
, и это не то, чтоmake
нужно делать. Опять же,make
не все о C, а встроенное в C решениеmake
- плохая идея (и, кстати, нарушение философии UNIX).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
:Или для развития Ады:
источник
Этот ответ дополняет ответ @lxrec.
Makefiles можно использовать для многих целей, а не просто для создания программы / библиотеки из исходного кода. Системы сборки, такие как CMake или autotools, предназначены для получения кода и его сборки таким образом, чтобы он подходил для платформы пользователя (т.е. находил библиотеки или определял правильные параметры компиляции). Например, у вас может быть make-файл, который помогает автоматизировать некоторые задачи выпуска, такие как: создать zip-файл, содержащий код с версией, полученной из git; запускать тесты против вашего кода; загрузить указанный zip-файл на какой-либо хостинг. Некоторые системы сборки (например, automake) могут обеспечить простой способ сделать это, другие - нет.
Это не значит, что для этого вам нужно использовать make-файлы, вы можете использовать язык сценариев (shell, python и т. Д.) Для таких задач.
источник
Я не думаю, что написанное человеком
Makefile
устарело, особенно когда:Makefile
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, будет компилироваться практически везде.
источник
autotools
в какой-то степени работает в системе Windows, например (не считая Cygwin / MingW, которая действительно является Unix-подобной системой поверх Windows).если ваш проект прост и содержит очень мало файлов, то файл make не требуется.
Однако, когда проект сложный, использует много областей памяти, имеет много файлов, тогда необходимо разместить каждую область памяти в нужном месте в адресуемой памяти, очень желательно не перекомпилировать каждый файл каждый раз, когда происходит тривиальное изменение. сделано в один файл,
Если вы хотите стереть старые файлы / compile / link / install с минимальным количеством хлопот и вероятностью ошибок нажатия клавиш, make-файл - это настоящее благо.
Когда вы попадаете в проекты «реального мира», редко бывает всего 1 или 2 файла, а скорее сотни файлов. make-файл всегда будет выполнять правильные действия, а не ненужные (после отладки), поэтому вы вводите только одну простую команду, а make-файл выполняет всю работу.
источник
make
болееcmake
или наоборот.