Благодарю за анализ и потраченное время, однако, основной целью было не найти окончательное решение (хотя это было бы интересно), а показать суть проблемы с build. Вряд ли я смог бы сейчас написать свой достаточный для целей задачи make-файл, но нашел более простое решение проблемы - миграция файлов в спец. структуры каталог перед компиляцией. Это не очень удобно в работе, но зато все замечательно собирается, запускается и работает. Более того, оное решение позволяет сделать свой фреймворк на c++ для драйверов (аля nu-mega, зачем - ниже). Полагаю, что та же беда при сборке и с фреймворком nu-mega.
nmake не пробовал, но в любом случае везде рекомендуется финальный драйвер собирать билдом, потому, видимо, и пробовать особо не стоит.
Идея такого разветвленного каталога очень проста - фрейморк (или application server) для драйвера: когда собирается очередной проект, то из фрейморка выдергиваются нужные классы(заранее отлаженные и протестированные) и включаются в свой проект, что позволяет значительно ускорить работу над проектом, а также мыслить более общими критериями по отношению к архитектуре проекта (кстати, если вспомнить !include - волосы дыбом встают). Слить все в кучу - значить запутаться в архитектуре своего фрейморка. Согласитесь, 200-300 cpp файлов в одном каталоге просматривать тоскливо, начинаешь забывать с чего начинал:)
Полагаю, идею своего фрейморка не будет отрицать ни один программист, поскольку все свои наработки надо где-то хранить. А поскольку китайский метод программирования в жизни работает не очень хорошо (copy + past), то лучше заранее нарисовать некий код с программным интерфейсом, его отладить и далее использовать через этот интерфейс. Собсно, это и есть фреймворк. Другое дело, как его оформить: кто-то пишет на асме, кто-то на c. Ну а тому, кто понял, что делать c с++, удобнее писать фрейморк на c++.
На форумах видел много высказываний, типа в драйвере на с++ писать нечего, ну и подтвержения - типа ms не c++ драйвера почти не пишет, значит - не надо. ИМХO, драйвера тоже бывают разные. Чем выше уровень абстракции драйвера от железа, тем больше там места для c++. Например, сравните драйвер файловой системы и драйвер сетевой карты. В ndis драйвере надо поддержать ряд определенных функций и далее просто прокинуть запрос в карту путем портов и аппаратной памяти карты. Вроде с++ тут и не нужен (но я бы и здесь нашел куда его приткнуть:), а вот в драйвере файловой системы надо уже учитывать объекты (файлы), их состояния (открыт-закрыт), права доступа к объекту и пр. И здесь очень логичным выглядит подход - для определенной группы функций иметь определенный контекст с данными. Собсно данные + код, помещенные в отдельный модуль - это и есть классический класс (либо его инстанс - объект). Итого, там где в драйвере создается контекст, я создаю объект:) Программисты, которые пишут драйвера на С просто не знают, что они пишут, фактически, на с++, только древним способом
Да и просто, это удобно. Например, я уж забыл когда последний раз в коде вызывал функции ядра работы со строкой: выделение/освобождение памяти под строку, преобразовать число в строку, склеить строки, сконвертировать unicode к ansi, автопроверка irql для строковой функции, вывод строки в файл, парсинг файла настроек. Из проблем посерьезнее - сборка ip И tcp пакетов для отслеживания хедеров этих протоколов, аналих трафика, имперсонализация клиента в драйвере-фильтре. Все - замечательно делится на модули и классы.
Не знаю причин, почему nu-mega перестала поддерживать свой фрейморк. Предположу, что такая штука будет не очень востребована на рынке, поскольку серьезных специалистов, которые пишут драйвера - единицы, а у них - уже есть свои наработки. Но для себя - просто милое дело:) Но кинем камешек потяжелее в сторону MS: после msvc шой-то это билд совсем как-то через известное место ..
Добавлено через 6 минут и 27 секунд:PS По Вашей ссылке:
After the scan is complete, the Build utility starts the NMAKE utility (Nmake.exe) to build the source files...
Видимо, build и так вызывает nmake. Так, что - без разницы.
