И ещё одна проблема: макросы могут нарушить такое свойство сборки, как воспроизводимость, а это означает крах всего. Решение уже давно понятно - нужно разделить процесс на два - один из них "грязный" и получает сведения из внешнего мира. В Си этим занимается configure. Сюда же относятся всяческие штуки, которые читают схему БД и на её основе генерируют какие-нибудь странички. Они должны сначала выгрузить схему в какой-то иной формат, чтобы сборка не лазала в SQL (хотя это на практике будет дико неудобно).
Что это означает? Что у нас нарушается двухэтапность макрорасширения. Сейчас принята модель, при которой модуль (ярм/Mod) при компиляции сначала проходит этап макрорасширения и получается файл мршм, который тоже является исходником на АО, но уже с расширенными макросами. Его мы и компилируем.
Оказывается, надо не так. Сначала происходит отдельно грязный этап сборки, где движок сборки АО ни за что не отвечает. Это просто некий скрипт, на выходе которого находятся файлы ярм/мршм или может быть какие-то данные (XML/БВыраж). А уже потом запускаются другие, чистые макросы. Но как будет обеспечена воспроизводимость сборки? То мне неведомо (пока).