возникла потребность/желание реализовать дополнительную обработку сишных текстов и хидеров собственной утилитой - искать и заменять текстовые строки. работаю с avr-gcc (WinAVR).
я так понимаю, для этого надо вклиниться в процесс компиляции или перед препроцессором или сразу после него перед компилятором (после препроцессора, пожалуй, лучше - так сразу будут обработаны и строки в хидерах).

как это сделать правильно? и как это затем "интегрировать" в Eclipse, который генерирует make-file самостоятельно?

В unix/linux подобную задачу можно решить скорее с помощью grep+sed. В makefile внести соответствующие вызовы.

?????

что-то нет ответов-советов... может, я недостаточно понятно изложил свою мысль? попробую пояснить.

дано: жидкокристаллический символьный индикатор типа WinStar 1602, знакогенератор которого содержит только расположенные в не поддающемся логике порядке символы русских букв, начертание которых не совпадает с английскими. то есть, символ 'к' в его знакогенераторе есть, а символа 'К' нет, т.к. его начертание совпадает с английской заглавной буквой K. и так далее.

проблема: разрабатываем программу для AVR, желаем вывести на индикатор "Привет, Мир!". если сделать это непосредственно, окажется, что на индикаторе полнейший бред, а не текст, потому что кодировка русских букв в редакторе Win-1251 (соответственно, и в прошивку они попадают в этой кодировке), а у индикатора кодировка извратная. существуют разные утилиты, которые конвертируют строки и позволяют вставить прямо в текст программы что-то типа "\240\239\168е\253", но это очень неудобно, т.к. в таком формате даже не понятно, что именно выводится - надо лепить комменты всякие и т.п.

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

какой вопрос возникает у меня.
допустим, утилитка конвертирует main.c в main1.c. как подсунуть main1.c вместо указанного в проекте main.c? в принципе, если makefile правится ручками, то особых проблем не возникает (хотя лично для меня это не совсем так - но это не главное в данный момент), но вот AVR Studio или Eclipse генерируют makefile самостоятельно, на лету строя его из различных "визуально заданных" параметров проекта. Вот и получается, что вручную вписать строчку в этом случае не получается: makefile перезаписывается автоматом и все...

утилитку свою прилагаю к сообщению. и очень жду советов по ситуации...

А кто мешает написать свой makefile и подсунуть и AVR Studio, и Eclipse? Сергей Борщ про это уже писал и я неоднократно поддакивал .
Если утилита командной строки (не смотрел ее), то все в makefile ложится легко, для облегчения отладки сделайте для утилиты отдельную цель, эту цель добавьте в правила сборки проекта.

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

Я понимаю, что мой совет немного не по теме, но.



Накладные расходы - 64 байта таблицы. Зато никаких геморроев с перекодировками

вообщето истинно правильный способ - не использовать среды которые навязывают makefile, ибо makefile - есть грань свободы за которую переступать нельзя.

в AVRStudio предлагаю два способа
первый правильный - котрый Вас не устраивает и предложенный выше коллегами:
выносите в отделный файл массив всех строк которые будите обрабатывать
генерится makefile студией
ставим галочку Use External Makefile
добавляем в цели сборки перед компиляцией вызов вашей утилиты котрая из внешнего файла будет генерить файл с преобразованными строками и который будет компилятся и линковатся

второй все тоже самое но с автоматичиеским makefile
прописать в меню Tools вызов вашей утилиты
когда вы правите файл с строками вызвать утилиту
компиляция


а табличным методом сделать ето на контроллере нельзя? строка -> буффер памяти -> переворачивание символов -> отправка на индикатор. так нельзя, избежите гимора ценой табличка переворачивания + буффер байтов ОЗУ ?

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

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

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

В Eclipse есть возможность задать "инстумент" перед компиляцией и после нее (Pre-Build Step и Post-Build Step), однако непонятно, как передать в запускаемую утилиту путь к файлам проекта и т.п. - хелп отсутствует почему-то

Дискуссия похоже заходит в тупик.
Вам klen предложил варианты и требуется Ваше решение по использованию этих советов.

Помнить все ключи компилятора не требуется. Правка makefile обычным редактором (я правил встроенным в Eclipse), ВСЁ нет необходимости править. Несколько строк. Кстати, а компилятор то в консоле запускается

2_Zltigo

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

+10

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

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

всеравно прийдется хотябы изучить как make работает.

Вот например - AVRStudio умеет только цеплять как компиллер GCC только файл avr-gcc и только. Зачем так сделано я даже не дагадываюсь. Едем дальше - есть "более лучший компиллер" с названием файла avr-impruve-gcc. И все - привед! танцы с бубном вокруг переименований файлов? незахочет студия им компилять, пока сам make не подсунеш в котором явно укажеш чем компилять.
Это конечно тривиальный пример, но когда таких ситуаций становится много - наченаеш плеватся.

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

вот наберусь сил разберусь с плагинами для нее.
можно будет сделать как в платных IDE
- парсинг XML описания кписталлов и при отладке все отрисовывать флаги, состояния, биты и тд

Хорошо вас понимаю. Комфортность работы - не последнее дело в процессе разработки. Чтобы не тратить силы на борьбу с побочными эффектами применяемых инструментов. Но вместе с тем, не могу согласиться, что руление через IDE есть удобный способ. Все эти IDE - они разные. Пересел на другую платформу и там все по-новой надо изучать. И помнить, что к чему при поднятии старых проектов (особенно, когда имел дело с ними давно). Поэтому единообразное управление на основе скриптов до сих пор является универсальным и самым мощным средством, а удобство - это во многом вопрос привычки: если постоянно возитесь со скриптами в разных проектах, то будет комфортнее поправить что-то в скрипте, нежели рыться в бесконечных табах и менюшках оболочки, когда уже все забыл, где что там лежит, т.к. последний раз сюда лазил два месяца назад (в лучшем случае). 

Что касается подсветки синтаксиса и т.п. Вот вы пишете программу в редакторе и ее вид вас не пугает. Более того, вы находите естественным этот способ описания функциональности вашего целевого проекта. Так почему же не использовать этот же способ и для управления инструментарием? Т.е. тоже в редакторе и тоже с подсветкой синтаксиса и code completion и прочими вкусностями. При этом вы не отягощены привязкой к какому-то конкретному интерфейсу, совершенно свободно сами определяете, как что и где разместить. Т.е. не только функциональность собственно скрипта, но и оформление его, так чтобы было самому удобно и понятно, где что и как размещено. 


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

Сам много лет работал с make. Начинал с борландовского, потом через непродолжительное время перешел на более продвинутый (хотя и со своими "гусями") GNU make. Процесс освоения шел довольно болезненно. Самым тяжелым для меня были две вещи. 

1. "Птичий" язык makefile - без документации под рукой частенько бывало не обойтись, дабы освежить все эти хитрые закорючки типа {:content:}lt;, $* и т.п., чем отличается $(@D) от $(<D) или от $(%D) и т.д. Сами выражения через постоянные подстановки - это надо иметь привычку, которая при работе с нормальными ЯП не требуется. 

2. Необходимость в дополнительных внешних утилитах и стыковки с ними. 

Года два-три назад нашел, наконец, то, что было нужно. Система сборки проектов на основе языка Python. Называется SCons. По принципам организации все похоже на make - вместо makefile используется корневой скрипт SConstruct. Но это уже скрипт на нормальном ЯП, с очень приятным синтаксисом и всем набором средств. Причем, работа со строками, файлами, обработка текста там как раз являются сильной стороной. Например, ваша задача решается там написанием фукнции, которая открывает исходный файл, генерит из него новый с обработанными местами и подсовывает компилятору этот измененный файл. Все средства как для выбора файла, его обработки, так и подсовывания, содержатся в самом инструменте. Никаких внешних дополнительных тулзов не нужно. И открыв, например, через полгода этот скрипт, все делается понятно, т.к. код сам по себе прозрачен и прост.

Сам SCons появился как развитие подобной системы на языке, кажется, Perl, которая называется Cons. Т.ч. если близок перл, а не питон, то это тоже вариант. Вроде, что-то подобное еще есть на языке Tcl (хотя у меня на Tcl аллергия ). Вообще, не хочу, чтобы мой пост воспринимался как реклама, хотелось бы только поставить акцент на том, что несмотря на большую заслуженность утилит make, их долгую службу на благо дела программизма, они не лишены системных недостатков, которые ограничивают их применимость и развитие. Поэтому имеет смысл обратить внимание на системы сборки нового поколения, основанные на скриптовых языках.

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

В любом случае, у Вас будет, например, в АВРовском проекте, достаточно ограниченное подмножество используемых ключей. Можно сделать заготовку со всеми используемыми опциями, и раскомментировать их по мере необходимости. Без лишнего дискомфорта.

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

Тут опечатка. Для "Ж" и для "Ч" одинаково записано "0xAB".
Если кто будет копипастить, то вот так вроде бы: