MSVC прекомпиляция

[Mayor]

Я создал проект с несколькими классами, чтобы обеспечить их взаимодействие в каждом модуле  включаю сцепляющий файл "MainHeader.h", который в свою очередь инклудит header каждого класса. В итоге, пока я вношу изменение в модуль перекомпилируется только он, но если в любой header - то все модули, даже те на которые это изменение не воздействует. Когда в проекте будет порядка 60 классов временные задержки окажутся весьма существенными.

Мождно ли как-нибудь ускорить процесс компиляции?

Или я опять неправильно задал вопрос - может следут обеспечить взаимодействие классов другим методом?

[Pu]

Mayor, та же фигня. У меня прога содержит классов 40 и если вношу изменения в какой либо хедер - иду пить чай   . послушаю эту тему тоже и с удовольствием.

[Алик]

Наверное, не пре-, а перекомпиляция?

[RXL]

Mayor, это зависимости. Поройся в проекте и отруби ненужные зависимости.

[lapulya]

Да просто не надо создавать этот файл

включаю сцепляющий файл "MainHeader.h", который в свою очередь инклудит header каждого класса.

надо просто в каждый cpp включать только те хеадеры которые нужны и все...
Соответственно перекомпяляться будут только те файлы (cpp) в которых включон инклуд в котором объявлен измененный класс.

[npak]

Mayor, когда MS VC компилирует исходники, он автоматически строит зависимости по включению (include).  Как правило, это заголовки, причём вложенные включения тоже учитываются.  Компилятор учитывает только файлы, а не лексемы, поэтому изменения в одном месте файла приводят к перекомпиляции всех зависимых .c или .cpp, вне зависимости от того, касаются их внесённые изменения или нет.

Есть два пути.  Разбить заголовки на отдельные кусочки, никогда не включать один заголовок в другой, в исходниках следить за тем, чтобы включались только необходимые заголовочные файлы.

Путь второй -- запретить компилятору генерировать зависимости. Для этого надо убрать ключик /FD из установок для проекта или для отдельных исходников (.c / .cpp)

[Mayor]

npak, спасибо.

Пойду почитаю про /FD для отдельных исходников

[Mayor]

npak, спасибо.

Пойду почитаю про то как это сделать для отдельных исходников.

[lapulya]

Я никогда не пользуюсь /FD - не переносимо.... поэтому лучше минимум инклудов в хеадерах (только при наследовании) и включение в cpp файлы ТОЛЬКО тех хеадеров которые реально используюстя в итоге компиляция проекта при изменениия хеадера минимальна, если же при пргоектировании отделить модули друг от друга посредствой ИНТЕРФЕЙСОВ (чисто абстрактных классов) то при изменении ВСЕХ хеадеров одного модуля перекомпиляция коснется ТОЛЬКО его... ну и + линьковка

[Mayor]

npak, /FD не канает - может потому-что я не понял как им пользоваться?

Единственное до чего я додумался - это запретить компиляцию ненужных модулей - тогда линкер просто пользуется заранее скомпилироваными .obj, но это очень неудобно, из-за того что делается это через GUI и  временами требуется изменять типы, а не добавлять новые в header. весьма забавная ситуация может случиться: в одном модуле в поле ссылка на BYTE, а в другом на DWORD, еще веселее будет если в одном модуле в классе поле типа short, а в другом int - особенно если выравнивание меньше 4 байт. Таким образом требуется как-то быстро переключаться между компиляцией отдельных модулей и всего проекта, иначе с GUI можно провозиться больше чем проект компилируется.

Нет ли какой возможности назначить горячей клавише компиляцию модуля в котором находится курсор?

И еще нельзя ли через #pragma comment(,) отменить компиляцию cpp файла без удаления\изменения его .obj файла? Иными словами компилятору подать один список cpp файлов, а линкеру другой список .obj файлов - естесcтвенно все из IDE.

[npak]

Mayor, /FD по умолчанию подставляется в командную строку запуска компилятора.  Открой Project->Settings, вкладка С/С++. Там внизу поле ввод Project Options, в него вбиты ключики командной строки компилятора.  Надо его прокрутить, и где-то ближе к концу обнаружится ключик /FD

Если его удалить, то при сборке проекта не будут учитываться зависимости по хедерам.

НО!  это чревато сильно неочевидными ошибками с распределением памяти.

Поэтому лучше переразбить заголовки на файлы меньших размеров и оптимизировать зависимости по включениям, чем потом сидеть в дампе памяти и разбираться, почему блок памяти портится, и системная библиотека валится при попытке его освободить.  Или почему магическим образом меняются байты без всякого внешнего повода.  Или ещё какие проблемы отлавливать.

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

[Mayor]

Странно, у меня что с /FD , что без него header зависимости проверяются

[npak]

А ты почисти каталог, в котором файл проекта лежит.  Из служебных файлов оставь только .dsp и .dsw

[Mayor]

Щас попробую прочистить

Единственное до чего я додумался - это запретить компиляцию ненужных модулей - тогда линкер просто пользуется заранее скомпилироваными .obj

Похоже я немного поторопился, link объединяет только те obj которые компилируются в данном build таким образом, он игнорирует остальные obj файлы в каталоге.
Как можно перехватить обращение IDE  к cl и link???

[npak]

Mayor, настройки вызова компилятора и линкера задаются в соответстствующих вкладках диалога Project->Settings

Если надо исключить некоторые файлы из сборки, то можшь на установках для этих файлов выставить галку exclude from build

Если тебе надо что-то сильно своё, то можешь написать makefile (в Visual Studio поставляется свой диалект, называется nmake).  У этого решения есть как плюсы, так и минусы.

[Mayor]

exclude from build не канает потому что мне надо чтобы модуль не компилировался но линковался

А как makefile из IDE запускать - чтобы он потом вывод отправил в Task Window - CT ошибки все таки надо искать

[npak]

Mayor, можно в Visual Studio подключить makefile как проект.  Тогда для сборки будет вызываться nmake

[SOS]

Mayor, npak,

Я бы всё таки к lapulya  прислушался
ДЕЛО говорит.

[npak]

SOS, так никто не спорит, что в C++ на этапе разработки надо оптимизировать заголовки.  Практика "один класс -- один заголовок" несколько непривычна для С/С++ девелоперов, но зато экономит время на перекомпиляцию.

[Mayor]

Угу точно - только мне nmake просто интереснее

[Mayor]

Mayor, можно в Visual Studio подключить makefile как проект. Тогда для сборки будет вызываться nmake

Ну чтож, похоже осталась толька пара макросов: как получить имя файла в окне, и макросом создать\изменить переменную окружения?

Кстати в командную строку nmake имеется возможность добавить свой макрос?

[Mayor]

Вроде бы я нашел решение, возможно опять поторопился - ну неважно:
после того как скомпилированы все obj файлы,
1. создается левый bat файл в который можно добавить приветствие
2. в FileView все cpp файлы, кроме того чей родной header планируется модифицировать, выделяются и в их установках выбирается always use custom biuld step, далее на соответствующей(ем) ...( ребята кто знает как называется хренотень расположеная под меню или заголовком окна которая меняет содержимое странички с рабочей областью ) в Commands вводится имя bat файла, в Outputs $(OutDir)\$(InputName).obj

Сейчас вроде все работает, но все равно это еще надо потестить в нормальном проекте... и если кто это рискнет юзать будьте поосторожней с выделением памяти под объекты и с опрерациями над указателями объектов ( ++ -- + - и тп ) в остальных модулях, в сомнительных ситуациях лучше перекомпилировать все без custom build step.

[npak]

Mayor, лень -- двигатель прогресса

Есть подозрение, что на борьбу с перекомпиляцией ты потратил времени больше, чем ушло бы на собственно перекомпиляции с зависимостями.  А всё от того, что лень ждать, пока оно всё пересоберётся

[Mayor]

Зато сколько нового узнал за все это время
Мне это еще пригодиться для m4.