Частота никакого отношения к опциям транслятора не имеет. Она задается в симуляторе, но это совсем другая история.

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

Только вот передать можно только факт определения символа, без значения.

Все так, только передавать дефайны таким перректальным способом как то не очень.

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

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

И каждый раз его править? Вместо того чтобы просто собрать конфигурацию с нужным кварцем.


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


Не видел ни одной IDE, в которой бы нельзя было определить символы препроцессору.
IAR:

Keil:

Visual Studio:

И, наконец, makefile:


Итого: проект собирается тремя разыми компиляторами (IAR, ARMCompiler и GCC) в трёх разных IDE и просто make. Никаких проблем переносимости и никаких правок исходного кода. Так что, вылезайте из танка, программируйте повзрослому.

Спойлер

Вложение:

изображение_2024-01-28_110329529.png [20.5 KiB]
Скачиваний: 538

Вложение:

изображение_2024-01-28_110950315.png [16.88 KiB]
Скачиваний: 534

Вложение:

изображение_2024-01-28_111443917.png [13.29 KiB]
Скачиваний: 533

Вложение:

изображение_2024-01-28_111906985.png [8.6 KiB]
Скачиваний: 521

Вложение:

изображение_2024-01-28_112139090.png [18.55 KiB]
Скачиваний: 526

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

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

Все с точностью до наоборот. Правят не код. Правят хедер. А точнее - просто управляют минимальным списком дефайнов.
В отличии от настроек среды или компилятора, хедер является частью проекта. Он читаем и адекватен. В отличии от.
Я беру исходник чужого проекта и он мне должен быть понятен и самодостаточен. Тогда нет необходимости таскать повсюду настройки среды в виде мейка. Достаточно только исходного текста.

Ну разве что у радиоинженеров.
В заголовочном файле не код? Вот это новость.
Вот первый попавшийся очень простой проект открыл. В нём 6 единиц трансляции и порядка 50 заголовочных файлов, не считая стандартных. И заголовочные файлы содержат примерно 80% кода. В каком из них искать заветный дефайн? В настройках проекта всё в одном месте.

Спойлер

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

Спойлер

Так не бывает. Не сможете вы его скомпилировать без настроек.

Спойлер

Вложение:

изображение_2024-01-28_155720133.png [37.4 KiB]
Скачиваний: 297

Вложение:

изображение_2024-01-28_155840752.png [27.38 KiB]
Скачиваний: 292

Вложение:

изображение_2024-01-28_161905454.png [30.78 KiB]
Скачиваний: 303

Это все пустой разговор для дилетантов. Обозначить хедер с настройками элементарно. Это main.h
И не нужно ничего искать. Прямо в его начале список всех опций проекта.
И чем провинился кварц? У меня список этих опций строк на 50. И каждой строке нужен коммент на пару строк. Иначе потом не разберешься. Мне эти комменты в мейк писать? Зачем? Чтобы какой то сторонний программер, который никогда не получит этот код по совершенно техническим причинам получил внутреннее удовлетворение?
Не катит, извините.
ЗЫ. И не нужно про плюсы. Мы люди простые. Нам достаточно чистого Си. Особенно для радиотехнических проектов.

Почему вы за других решаете надо или нет? a.garkin спрашивал КАК сделать, значит ему надо.

ЗЫ: Я что-то писал про плюсы?

Конечно не смогу. Если код подразумевает эти настройки.
А если не подразумевает, то смогу.
Осталось задать логичный вопрос. Кто писал такой код? С настройками кода в мейке...

Добавлено after 3 minutes 28 seconds:

Ему только так кажется. А есть гораздо более естественный путь.

a.garkin, вот так получается передать параметр у GCC. Умеет ли так ваш компилятор не знаю.

Вот это в коде как true срабатывает


Добавлено after 2 minutes 15 seconds:
Остаётся задать логичный вопрос. Вы писали что-нибудь сложнее "Hello world"?
Кто вас уполномочил это решать?

Добавлено after 30 minutes 48 seconds:
Посмотрел лог, вот сколько параметров Visual Studio передаёт компилятору. И это ещё лайтовенько, без директив препроцессора. Все они из настроек проекта взяты. Имея только исходники ой как долго вы будете собирать...

А ещё такую же пачку, если не больше, линкеру.

О чем можно дальше вообще говорить?


У вас профессиональная деформация.
Тут ветка про Микрочип. Более того, вопрос поднят даже не про АРМы.
К чему этот треп про VS?
Одно дело, когда речь идет о дебаге на фоне кода в продакшен и совсем иное - совать в мейк обычные дефайны.
Не путайте теплое с мягким в эмбедде внутрисхемного уровня.

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

Потому что это такая же IDE как и ваша MPLAB и точно так же работает с компилятором. Мне на её примере проще показать как собирается проект.


Это обычное управление проектом. Если проект управляется мэйкфайлом, то в нём всё и задаётся. Представьте ситуацию, что у вас есть несколько конфигураций проекта с разными кварцами. Допустим, вы исправили кусок кода работы c UART (или чем либо на ваш выбор). Для сборки этих конфигураций с новым исходным кодом не надо править исходники, а просто запустить make с параметром. Либо в IDE нажать кнопку build на нужных конфигурациях. Либо вообще на серверах сборки собирают. Так делают программисты. А вот радиогубители лазят по заголовочным файлам и правят их туда-сюда.

Это что за зверь такой?

Абисняю. Это такой зверь, когда за очень грамотным, не хуже вас, программистом, приходится переписывать почти весь проект. Просто потому, что он не радиогубитель, а тупо погромист. И ничего не понимает в радиотехнике.
Но у него все очень правильно и традиционно с точки зрения его самого. Правда эта правильность и традиционность никак не способствует получению товарного изделия.
Это так бывает. И зависит от места занимаемого вычислительной системой в изделии. Ну и от организации и структуры R&D. Чем разгребать чужой и красивый код, лучше написать свой. По своему красивый и не менее правильный.
ЗЫ. У меня весьма богатый опыт взаимодействия с программистами. Поверьте мне.

Понятно. А то я чуть не подумал, что это как-то к сути обсуждаемого вопроса относится.

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

Судя по тому что вы описали в предыдущем сообщение, сначала сами научитесь работать, чтобы не переписывать, затем других учить будете.