Средства и методы разработки

Размышления и вопросы около Считаю, что вместо неосязаемых (пока?) "программных модулей", которые на слух понимаются как workspace/project в известных тулзах типа IAR, действительно имеет смысл получить нечто;) в более регулярном формате, но скажите, а не проще ли отпарсить файлы проектов (не входящих в проект, а содержащих дерево и пр. - обычно их один-два) применяемых тулзов и отконвертить результат в нужный формат? А не проще ли формально выделить блок с прототипами функций в ОТДЕЛЬНЫЙ блок текста (типа как в Паскале и т.п.), чтобы натравить (если уж решили) шнягу, которая пережует чего-то в специальном блоке? А потом грести по совпадениям текста? Тогда никто не мешает для обработки мест употребления вспомнить встроенный в Си макрос __LINE__, скажем вставляя данные из него в метки на этапе постобработки? Нахрена тогда эти/идентификаторы, если уже есть имя, а file:line находится по имени этой внешней тулзой? Даже без макроса __LINE__? Проблемы видятся в ручном "регистрировании" функций. Особенно в различениии библиотечных (причём используемых в тексте) и описанных по месту, а также попавших в некомпилируемый текст (комменты, условная компиляция). Дабы этого не придумывать, видится прямой путь - воспользоваться обычно присутствующими возможностями по запуску препроцессора (кажись ключ -E в GCC). Но этого мало - вроде бы для общего понимания состава проекта нужно полное дерево проекта, но в конкретный момент нужен результат конкретного конфига. Потому вспоминается старый добрый вариант с библиотеками - что туда попало, уже, считай, обработано документописательством, иначе пользоваться толком и нельзя;) А дальше вопрос - а кто же библиотекарь? Хрен с ним с библиотекарем. Всё это напоминает попытки разрулить одинаковое текстовое представление модификатора extern в Си, как-то уже разруленное в плюсах через public и import. Сам часто применяю (старая идея от Al) макросы #define __public extern #define __import extern в проектах на Си, дабы самому не запутаться. Главное, что такое парсится без проблем, а пишется писателями добровольно-принудительно согласно правил проекта. Короче, как по мне, главный вопрос - не в технологии обнаружения/регистрации/идентификации, а в рулении всем этим добром. Но всё это фигня, если, а таковое обязательно будет, рождение некоторых "сущностей" (например, ещё и при использованиии ОС) определяется данными, а не программистом. Но всё же гораздо интереснее со списками/очередями, потому как они, ИМХО, чисто виртуальные объекты, ещё и в некоторых случаях не имеющие выраженного заголовка (сам такое иноогда употребляю;)... Область определения, ИМХО, нужна более чёткая