Кто может разъяснить зачем нужен makefile?! На просторах интернета внятной информации не нашел. К примеру в некоторых темах пишут что при правки makefile нужно указывать тип микроконтроллера, рабочаю частоту и т. д. Я работаю в atmel studio и там в makefile нет таких пунктов. Просто хочется для общего развития понимать зачем он нужен и почему он бывает разный.

На просторах интернета информации о make выше крыши, очень странно, что не нашли. Можете начать отсюда и далее по ссылкам.

Makefile изначально использовался в среде типа UNIX, которые построены на парадигме управления задачами посредством команд, которые вводятся в консоли (символьной -- а графических консолей тогда и не было) с клавиатыры. Результат выполнения также отображался в символьном виде на экране тойже консоли. Вместо экрана висплея можно было подключить принтер. А почему бы нет!

Ну Вы поняли! Кнопочек и менюшечек не было. Мышей -- тоже. А управлять заданиями, то есть работать на компе было нужно. Вопрос -- как? Единственный выход в те времена -- использование клавиатуры и экрана (принтера). Понтное дело, что при таком раскладе ни о какой графике говорить уже не приходилось. Команды системе отдавались в виде слов, и получение резултата вываливалось на экран тоже в виде слов.

Ну это прописные истины. Я их сказал тоько для того, что бы мы понимали друг друга однозначно. Идем дальше.

Набирать какжый раз серию команд было неудобно. Поэтому встал вопрос об автоматизации действий программиста (пользователя). Одно из направлений автоматизации было использование скриптовых файлов, в которых команды записывались по-сторочно. Это в некоторой степени аналог виндовых BAT-файлов.

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

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

В Видовсе принято программировать мышкой. Поэтой причине в Виндовсе Makefile-ы не очень распространены. И правда, какой смысл в файле, если все параметры контролируются средой разработки (IDE), и сама среда уже знает какой компилятор использовать?

Если Вы не собираетесь пробовать Линукс, то и заморачиваться особо на эти Makefiles Вам нет никакого смысла. Это в среде Линукса зание Makefile жизненно необходимо.

Atmel Studio генерирует Makefile на основе данных проекта и использует его для сборки. Если посмотреть в директории со всякими временным файлами рядом с проектом, то там и найдется Makefile.

Atmel Studio так же позволяет указать внешний Makefile. Единственная настройка в этом случае - это путь к файлу.

Обалдеть, а как быть с тем фактом, что все эти движения "мышкой" генерят на самом деле именно makefile (или их эрацы), только жутко корявые и убогие?
Посему нормальный путь это не уподобление неандертальцам выражающими свои мысли наскальной живописью, а испольовать разившуюся за тысячилетия письменность. Я напимер, уже больше десятка лет из линукса ущел окончательно, пользую около дюжины компиляторов в win и все с make. Причем пользовал в те времена, когда линукса да и виндовса просто не было, компиляторы были хреноватые, но ассемблеры были.

Наскальная живопись, увы, возможна везде и в этом отношении IDE позволяющие "программировать" мышкой везде одинаковы и уже в подавляющем числе случаев уже ПОРТИРУЮТСЯ из линуксов в виндовс

zhevak, спасибо за ответ! В общих чертах я понял про makefile. Мне больше не понятно другое, к примеру берем какой нибудь чужой проект с всеми исходниками и makefileом, в makefile указан тип микроконтроллера и рабочаю частота. Или другой пример, решил я почитать про bootloaded, нашел тему где все подробно расписано и есть все исходники и makefile, опять-же там указывается тип и частота. Я работаю в atmel studio 6, там автоматически генерируется makefile, но там нет таких пунктов. Вот мне и не понятно почему где-то указывается тип и частота а где-то нет.

Потому что не нужны они студии. Makefile - это просто список рецептов и зависимотстей между ними. Он может содержать все что угодно.

Задача то какая? Взять проект с makefile-ом и собрать его в атмел-студии? Берите исходники, добавляйте их в студийный проект и собирайте. Процессор в студии где-то точно выбирается. Что такое частота? Некий define, заданный в makefile, который потом используется в исходниках? Подозреваю, что в GUI студии есть возможность указать произвольные define-ы...

Ну т.е. в makefile все опции компилятора заданы напрямую, текстом. В студии их надо задавать через окно свойств проекта.

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

Не только, есть еще использование переменных enviroment. Ну и управление проектом это не только "опции компилятора". В реальности проект это зачастую вобще не одно изделие, а группа устройств, зачастую даже на разных контролерах и под разные компиляторы. Прелесть ПОЛНОГО контроля, и в том, что я могу описать правила сборки действительно ВСЕГО проекта со всеми вариантами.

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

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

Давайте подумаем вот на какую тему -- а на что, собственно, влияет тактовая частота процессора в программе?

Делаю паузу, чтобы Вы сам попробовали ответить на это вопрос.

Подумайте хояты минуту, прежде чем читать далее.

На скорость сборки проекта или на состав проекта (из каких файлов будет состоять прект) тактовая частота никак не влияет. Это понятно.

Тактовая частота влияет на скорость работы самой программы. Тоже абсолютно прозрачно. Однако, код, удачно откомпилированный и залитый в кремний, будет работать как с одной тактовой частотой, так и с другой с другой -- будь они различными хоть в 100 раз! Ну, какая разница с какой скоростью моргает светодиод или опрашивается кнопочка? Нехватает скорость? -- Припаяй другой кварц! Программа принципиально будет работать. Поэтому в этом и предыдущем случае задавать тактовую частоту в мэйкфайле нет ни какого смысла. Этот параметр ведь никак не будет использоваться в программе.

Другое дело, когда в вашей программе нужно четко соблюдать время и/или временные интервалы. Нпример, синхроимпульс, который вырабатывает ваше устройство должен иметь длительность ровно 100 мкс. Или последовательный порт UART должен работать на скорости 9600 бод. В этих случаях где-то в программном коде будут вычисляться коэффициенты для таймеров, для UART-ов или количество пустых циклов для программной задержки.

Есть два варианта. Первый -- вы вручную (на калькуляторе, на бумажке или еще как-нибудь) посчитли значения коэффициентов, то есть получили числовые константы и напрямую забили их в программый код. Ну, например, вы вычислили, что для задержки 100 мкс вам требуется 36 циклов. Тогда вы тупо пишите:


Или для того чтобы UART работал на скорости 9600 бод в регистр UBBRL нужно записать значение 49:


В этом коде значение тактовой частоты тоже отсутствует.

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


Тогда в программе для рассчета количества циклов и коэффициента для UBBR прямо в тексте исходного кода може использовать эту константу для вычисления нужных значений:



Удобство в этом случае состоит в том, что теоретически вам уже не нужно вычислять все коэффициенты в ручную. Оптимизирующие компиляторы вычисления сделают за вас и в код микроконтроллера попадет уже готовое значение коэффициента. То есть компилятор сгенерирует не команды, вычичляющие коэффициент, а уже готовую констатну. Я сказал -- "теоретически". Практически же, понятное дело, лучше такие вещи все-же проконтролировать. У меня по жизни несколько раз были случаи, когда вычисления вылетали за диапазон допустимых значений. Приходилось код подправлять ручками. Собственно, в этом и состоит труд разработчика-программиста.

Идем дальше.

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

В нашем предыдущем коде символами являются следующие дефиниции: FCPU, BAUD, delay100ms, UBBRL. Какие-то из символов уйдут при компиляции, какие-то остануться вплоть до elf-файла. Ну, например, FCPU и BAUD скорее всего вы уже не найдете в elf-файле? А вот delay100ms -- он будет отаваться долго. Если вы пишите прогу для компа, а не для микроконтроллера, то этот символ также будет присутствовать и в исполняемом файле, если вы ничего специально не предпримите для его (точнее -- для их) удаления.

Так вот, символ -- это какая-то программная единица с уникальным именем.

До сих пор мы с вам говорили о символах, которые определены в программном коде. Но символы можно также определить (или задать) вне исходных текстов программы. Например, подставлять их в качестве параметра в строку при вызове компилятора:



Это почти реальная строка для компиляции файла myproga.c в объектный файл myproga.o. Здесь компилятор -- avr-gcc, тип процессора atmega32, ну и так далее.

Обратите внимание на параметр -DF_CPU=7372800UL. Понятно, что эта конструкция определяет тактовую частоту. Но как! Имя "F_CPU" -- это ни что иное как символ. Конструкция "-D" -- это имя параметра. Черточка '-' говорит компилятору, что далее последует имя ключа. (В Виндовсе обычно используется знак '/' а не черточка.) Буква 'D' -- имя ключа, производное от слова DEFINE. И сразу за именем ключа следут имя символа. С непривычки это , конечно, кажетя одиозным! Чужая идеология, чужие понятия, чужие ценности. Но тот, кто постоянно этим пользуется не видят вообще ни каких проблем. Проблема чистов перестройке мышления. Однако, мы отошли от темы!

Так вот. С точки зрения компилятора, ему нет никакой разницы в том, откуда к нему пришел тот или иной символ -- из исходного теста программы или из командной строки. Во время совей работы компилятор составляет таблицы символов. И как в эту втаблицу попадают символы -- дело десятое. Главное чтобы таблица была и была валидной в работе.

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



и далее в этом Makefile их использовать для компиляции вот так:




или что тоже самое:



Ну, вроде бы доходчиво объяснил, откуда что берется.

И да! Чуть не забыл. Если вы посмотрите на проекты, в которых используется ARM-ы, то вы увидите, что символы задаются не только в исходниках и Makefile. Символы задаются еще и в ld-файле, который отвечает за сборку проекта. Тут вы найдете такие символы, как адреса начала оперативной памяти, ее размера. начало и размер флешь-памяти. Названия секций (text, data, bss и другие). И многие другие нужные символы.

Это по началу кажется очень сложным. Но когда познакомишься с "механикой", то начинаешь приходить к мысли, что ты реально Бог для своего проекта. Всё, абсолютно всё в твоей власти. И ты четко понимаешь как всё устроено и как на выходе получается код. Всё открыто, всё прзрачно. И самое главное -- что нужно сделать, чтобы внести те или иные изменения.

Ладно. Много напасал. Бодрости духа вам и здоровья! Остальное добудете сами!

zhevak, Получается что если проект состоит из не скольких файлов, и допустим в каждом файле используется delay функция, для которой необходимо знать тактовую частоту. И чтоб не указывать в каждом файле F_CPU, можно ее указать один раз в makefile. И тогда компилятор сам подставит ее там где она необходима. Я правильно понял?

Указав MCU мы сообщаем компилятору с каким микроконтроллером работаем чтоб подключить необходимый файл <avr/ioXXXX.h>?

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


Ничего Вы не поняли . Все, что Вы написали можно сделать разными способами, в том числе, конечно, в make, но это скорее решение через анус, которое рожают, как правило только безумные генераторы маке файлов из всяких IDE сшивающие белыми нитками всякие "универсальные" заготовки в малочитаемое макроме. Первое, что надо сделать, это НЕ читать такой ужас, а просто медленно и спокойно начинать выражать свою мысль. make МНОГО проще, нежели может показаться при попытке изучать его по творениям автогенераторов.

zltigo, Ну если я ни чего не понял, тогда объясните пожалуйста тогда зачем в makefile указывается F_CPU и MCU.

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

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



всё очень просто. Если какое либо имя у Вас вызывает вопрос - то смотрите кому оно скармливается. Ну например компилятору.
Далее вызываете из командной строчки компилятор с ключом помощи и читаете про ключик который стоит перед этим именем.
Далее становится понятно, что либо это использует сам компилятор(как пример) как управляющее слово, либо он его передаёт
в пространство имён на этап компиляции(как пример).

Именно в makefile, а не, например, в Вашем персональном хидере, исключительно по дурости для "удобства" автогенератора запихивающего в один файл все, что попало.

1. Про F_CPU.

Да. В целом Вы поняли правильно.

Знающие люди выше уже заметили, что __символ__ F_CPU можно опрелеить где угодно! С точки зрения компилятора процесс компиляции будет успешет, если вы зададите значение в:

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

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

3) в командной строке вызова компилятора. Ну, это бывает редко. В основном тогда, когда по каким-то причинам вы не хотите оспользовать Makefile. Ну например, написали короткую прогу с целью протестировать работу компаратора, поиграться, попробовать -- а как это будет вообще работать. Городить проек, создавать специально для этого отдельный Makefile -- не очень разумно. Поэтому можно вызвать компиляцию руками. Но я об этом уже писал выше.

4) в Makefile. Наверно это наиболее правильное место для указания тактовой частоты. Makefile -- это пульт управления проектом, поэтому всё глобальное лучше выносить сюда. По крайне мере то, что касается всех файлов проекта, уже не придется искать по всем файлам проекта. Однако, по большому счету, значение F_CPU в процессе работы мэйкфайла так или иначе попадат в командную строку при вызове компилятора. То есть это пять же разновидность случая 3).


2. Про MCU. Я не знаю как сейчас делается в Виндовых компиляторах (уже лет 7 как избавился от неё). Я расскажу как это делается в gnu-компиляторе под Линуксом. А как оно будет под Виндой, я думаю, по аналогии Вы и сам догадаетесь.

Допустим, в командной строке при вызове компилятора вы передаете параметр MCU=atmega328p.

В каждом файле с исходным кодом должен быть "прописан" хэдер:



Причем, эта директива должна прискутствовать в любом исходнике независимо от типа AVR-микроконтроллера. Иначе говоря, сегодня вы пишите код для ATMEGA168P, а завтра вам нехватило ресурсов и вы решили перейти на ATMEGA328P. Для этого шага вам достаточно поменять тип процессара в Makefile. Ползать по всем исходникам не надо!

Теперь идем в директорий /usr/lib/avr/include/avr и открываем файл io.h. В нем есть такие строчки:



Ага! Значит, комппиялтор подцепит правильный заголовочный файл, где определены регистры и другие ресурсы нашего микроконтроллера.

Вот тут критики-тролли могут упрекнуть меня в том, что в Makefile указано значение "atmega328p", а выбор хэдерного файла под процессор осуществляется на основе имени "__AVR_ATmega328P__". То есть, имена не совпадают. Как же так?

Ну, вот так, господа! В компиляторе "зашита" таблица соответстви этих имен. То есть компилятор из командной строки считывает "atmega328p", затем производит поиск в этой таблице, и в таблицу символов попадет "__AVR_ATmega328P__", а не "atmega328p". А далее, всё идет традиционно. Зачем так это сделано, я не знаю.

zhevak, Спасибо вам большое, за подробные и развернутые ответы!!! Вроде более менее все уяснил)))

А чем эта вдруг стала какой-то особо глобальной и какой-то особенной? Чем это число лучше какой-нибудь другой частоты, типа SPI, или немалого количества ключей условной компиляции? C чего это она вдруг стала касаться всех файлов проекта? И почему это вдруг остальные можно "искать по всем файлам проекта", а ее нельзя? Вообще-то никакие дефиниции не стоит искать по всем файлам и посему правильно сложить их в ОДИН общий заголовочный файл, а не разбрасывать по разным да еще в make запихивать для полного счасттья

А за такое, как Вы описали, вообще надо бить больно. Вместо того что-бы написать в одном общем хидере
#include <avr/iom328p.h>
разводится пляски с MCU. Ну откуда сие растет понятно - из демок - там один исходник для какой-либо супер-программы типа "контроллер светодиода", которой пофиг под чего ее компилируют, посему и один "универсальный" исходник, да и один развестый make кторый собирает за раз 999 прошивок. Реальность обычно другая, но попугайничают по образу и подобию


А вот за это действительно Спасибо!

А вот тут препроцессор будет громко материться:

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

-- У тебя мама был? Папа был? А почему злой, как собака?

Ведь всё очень просто. Если тебя что-то не устраивает в этом мире, то сделай это сам или исправь, а не указывай другим как это следует делать. А если не можешь, тогда пользуйся тем, что есть, и благодари за то, что есть хотя бы это. (Ну, либо не пользуйся совсем. К стати, не замечал, как смешно выглядит те, кто критикует то, чем сам не пользуется?) Если сделаешь что-то доброе для общества, то общество будет тебе благодарно. А если у тебя получиться реально полезная вещь, то можешь даже просить за неё денежное вознаграждение. А если ты не можешь ни улучшить, ни создать свое, то наверно не стоит указывать тем, кто может и делает. И уж тем более определять степень и меру наказания.

Я у Вас, или кого либо простил что-то исправить? Вроде нет. А вот Автор, точно спрашивал, как и что делать.

Я могу, посему НЕ пользусь и посему считаю необходимым не только благодарить, но и критиковать, то чем НЕ пользуюсь и что приходится переделывать за творцами (а то и "творцами" ) реализующими прежде всего свои собственные цели.
А лично Вам http://electronix.ru/forum/index.php?showt...t&p=1358239 я спасибо говорил. И еще не раз могу повторить - спасибо! Спасибо за то, что взяли на себя труд ПОДРОБНО начать разьяснять непонимающим приемы работы и один из инструментов, который позволяют им НЕ быть рабами всяких "атмелов" c их "студиями" с галочками.

@zltigo
Мои извинения. Наверно я не правильно Вас понял.

Все номально!

нетривиального makefile вообще как-то не хочется... потому что они никогда не работают как надо.

Вообще-то они работают, как Вы приказали и, если, не "не как надо" уже чисто на Вашей совести. Make штука в общем несложная и вылизанная поколениями программистов, так-что она реально работает.

Рискну пойти против течения... но в абсолютному большинству makefile не нужен, и более того, ошибочно построенный makefile опасен для собираемого проекта. Для сборки и работы с проектами, состоящими из 10-20 файлов, вполне достаточно скрипта или bat-файла в духе

Основное преимущество makefile перед подобного рода скриптами сборки заключается в возможности построить четкую иерархию проекта, то есть зависимости одних файлов от других, и при модификации одного файла не пересобирать все файлы заново, а только те, которые зависят от отредактированного файла. В этом же состоит и опасность - при неправильно описанной иерархии проекта можно попасть в ситуацию, когда файл отредактирован, а изменения не вступают в силу по причине того, что make не видит изменения цели сборки, и соответственно не перекомпилирует нужные файлы. Особенно это касается заголовочных файлов.
Поэтому если весь проект компилируется не более 10 секунд, смысла влезать в ручное написания makefile нет никакого, проще пересобирать всё. Ощутимую экономию времени make приносит на проектах объема порядка линуксового ядра.

Вы правы и не правы одновременно.
Многое зависит от организации работы. Например если проектов на сборке много, и нет возможности использовать параллельную компиляцию
исходников и сильные вертикальные зависимости; и политика непрерывной интеграции требует наименьшего времени для контроля качества всего
продукта - вот тут и вылезают все прелести ребилд олл...
И встаёт вопрос - один раз довести до ума механизм, либо терять в день до нескольких часов...
я думаю осадок понятен - что выбирают в качестве решения.

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

Вообще-то неправильно написать bat ни чуть несложнее, чем make. Да и пересобирать полностью, если неуверенность в том, что сотворили терзает душу, так-же легко и make позволяет.
Хотелось-бы так-же услышать нет-ли вдруг каких опасностей таящихся в ошибочных исходных текстах???