ReAl

У зв’язку з описаною раніше помилкою avr-ld та методом боротьби з нею мене спитали про той «універсальний» файл gcc-avr.mak, яким я користуюся у всіх проектах. «Нічого воєнного», це просто файл, у який зібрано команди, які без змін переходили б з проекту в проект шляхом копіювання (і наступного редагування) Makefile від попереднього проекту 😉

Тепер файл gcc-avr.mak підключається до Makefile проекту командою include. Так само, як і подібний мейк-файл для роботи з програматором avreal — avreal.mak. Файл для проекту тепер короткий, містить лише головні налаштування. Легше знайти потрібне, важче поламати те, що вже перевірене.

Повернімося тепер до цього універсального мейк-файлу для avr-gcc і до згаданої помилки в avr-ld.

Окрім іншого, на початку gcc-avr.mak здійснюється налаштування шляхів до програм, використовуваних при компіляції. Виглядає це так (нумерація рядків відповідає файлу, доданому у прикріплений архів).

Зроблено це було ще у ті часи, коли я багато працював паралельно з різними версіями avr-gcc з різних джерел. Частково тому, що все «дихало», нові версії мали кращу оптимізацію, але могли «глюкнути» і потрібно було мати можливість швидко відкотитися на перевірену версію. Частково тому, що я активно розвивав і супроводжував AVR-порти scmRTOS і треба було перевіряти всі зміни у різних версіях компіляторів, вишукувати «інтерференцію» помилок і «особливостей» ;-). Тоді найперевіреніша і найстабільніша версія avr-gcc була встановлена основною за допомогою команди junction (див. допис Різні версії WinAVR поруч). У файлі gcc-avr.mak підключалася ця основна версія — але лише тоді, коли змінна TOOL не була встановлена у Makefile проекту. У проекті ж цей рядок або був відсутнім, або міг мати вигляд:

Ще у цьому gcc-avr.mak, у його варіанті для Windows, були рядки, які приводили до єдиного вигляду шляхи у змінній PATH і експортували її для процесів, викликаних make. Це було пов’язане з необхідністю змусити працювати на одному комп’ютері avr-gcc з різних джерел. Якщо коротко, то ті, що спиралися на MSYS, і ті, що були зібрані геть автономно, використовували шляхи вигляду /c/directory і c:\directory відповідно. Це теж окрема пісня, яка тепер для мене цікава лише в історичному плані. Якщо комусь цікаво почути — проспіваю окремо.

Ну так от, оця змінна TOOL виявилася найкращим місцем для додавання заміни значення змінної оточення LANG (дивись вже згаданий допис щодо виправлення помилки переповнення буфера в avr-ld):

Позаяк змінна є префіксом для всіх інструментів, вона ж превентивно перемикає мову і для інших програм пакету. Файл цей у мене лежить один на всі проекти, тому вони всі відразу виправилися. Добре, на всі проекти з однієї групи, тому все ж таки по внесенні змін мені довелося його розкопіювати у декілька місць. І я так і не зробив собі репозиторію для загально-загальних файлів.

Додаю архів із дуже-демо-проектом, який має використовувану мною структуру каталогів.
Там є спільниі для всіх проектів «бібліотеки» (каталог common, що може містити як підкаталоги незалежних від архітектури мікроконтролера модулів, так і залежні, наприклад, common/avr, що може своєю чергою містити підкаталоги з контролеро-залежними модулями). На цьому ж рівні знаходиться спільний для всіх каталог tools, де живуть спільні (для групи проектів) скрипти і підкаталог tools/makefiles зі згаданими «універсальними» файлами. Всі проекти (представлені одним-однісіньким project1) мають схожу структуру. На верхньому рівні проекту живе його Makefile а також файли середовища програмування (у мене це Code::Blocks) і, при необхідності, деякі додаткові персональні скрипти. У підкаталозі src для простих проектів лежсть всі їхні тексти, у складніших — ще підкаталоги з модулями.

«Модуль» (мають бути перелічені у змінній MODULES у Makefile проекту) у контексті цього підходу є каталог, який може бути підключеним до проекту як одне ціле. Окремі файли ніде не перелічуються, gcc-avr.mak автоматично включає у компіляцію і лінкування всі асемблерні, C-шні і C++-ні файли, які у цих каталогах знаходить. Таким чином, «модуль» у цьому розумінні може містити декілька модулів у термінах програмування, які можуть бути використані у проекті лише разом. Так само «модулем» може бути каталог із лише h-файлами, які пов’язані між собою лише тим, що стосуються однієї сім’ї мікроконтролерів і ніяк більше не пов’язані між собою. Весь каталог буде підключено до проекту, а які конкретно файли будуть використані — залежить від директив #include у файлах проекту.

Описувати це довше, ніж читати самі файли. Беріть як є.
Прикрутити таку систему можна до будь-якого інтегрованого середовища, яке дозволяє зробити проект «із зовнішнім Makefile». При цьому, напевне, будуть втрачені якісь зручні можливості середовища по налаштуванню проекту, але можна нашвидкоруч щось підправити у vim чи gedit, а тоді з консолі набрати make program :-).

p.s. Раніше я писав про те, що можна зробити в gcc (avr-gcc) з використанням секцій (дописи «Використання секцій в GCC» і «Секції .init в avr-gcc»). Робота з Makefile і gcc-avr.mak згадані там лише побіжно, але у прикріплених архівах є реалістичніші проекти з використанням такої техніки роботи з мейк-файлами «модулями».