[Qt 4.2.x] Зависимости от *.h файлов

[Tonal]

Такая проблема: при изменении *.h файла зависимые от него *.cpp не перекомпиляются...
Можно ли, и как прописать в *.pro файле зависимости между *.cpp и *.h файлами?
Или, в идеале, прописать какую-нибудь коммандочку, чтобы эти зависимости сами отстраивались и перегенерялись.
Работаю под Win-дой, компилятор mingw.

[Admin]

очень странно! так как должны были обязательно

PS: есть такой глючек, если время модификации cpp и h разное
тоесть как бы cpp в будущем а h в прошедшем то копмилятор творит такие вещи

он смотрит на даты фодификации файлов

[Tonal]

Оказалось, бага горазда замысловатее, чем я описывал.
Пока чисто воспроизвести не получается.
Может это связано ещё и с SVN-ом.
Так что будем копать дальше. ;-)

[Admin]

а SVN то сюда как попал?

[Dendy]

Зависимости от файлов - зловредная штука. Иерархия зависимостей компилируемого файла должна бьІть отслежена по самьІе корни ДО процесса компиляции, чтобьІ make мог мгновенно узнать, стоит ли обновлять зависимьІй файл или нет.

Из оболочки ето делается легко. Та же студия хранит свои временньІе файльІ зависимостей и постоянно их отслеживает на лету.

Но при компиляции через Makefile вьІлезают грабли. Ибо стоит нам добавить включение нового заголовочника - вьІшестоящая ветка пересоздастся, НО(!) зависимость от нового заголовочника не добавится и как следствие - изменение тела етого нового заголовочника не отразится на сборке. Error.

Процесс генерации зависимостей процесс тяжёльІй. Шутка ли - перегрести ВСЕ исходники своего проекта и всех библиотек, что в нём используются.

ПрофессиональІ рекомендуют прописьІвать правила, создающие для каждого исходника в проекте свой Makefile с зависимостями, которьІй автоматически будет пересоздаваться при изменении одной из них. Ето самьІй рациональньІй метод из существующих.

В Qt сборкой зависимостей занимается qmake. Делает ето достаточно еффективно для всего проекта сразу. При всей кажущейся избьІточности (каждьІй раз шуршать по исходникам и полностью пересоздавать Makefile) делает он ето более чем бьІстро. Гораздо бьІстрее, чем при создании Makefile'ов отдельно для каждого исходника проекта.

Так что когда в документации по сборке пишут:
qmake
make
- делают ето не зря. Даже если .pro файл не изменялся после последней генерации Makefile'а. Если бьІла изменена зависимость - будьте готовьІ к тому, что проект соберётся НЕПРАВИЛЬНО при использовании одной лишь:
make
Знайте, ето не глюк. Не нужно чистить проект под чистую и пересобирать его. Нужно всего-лишь пересоздать Makefile и запустить процесс билда снова.

[Tonal]

а SVN то сюда как попал?

Как вы версии файлов проекта контролирует. ;-)
У нас не любой проект, длящийся дольше рабочего дня попадает в свин.

Так что когда в документации по сборке пишут:
qmake
make
- делают это не зря.

qmake ProgName.pro и прописано в Slick-е на как Pre Build Command.

И тем не менее глюки бывают, но к сожалению чисто воспроизвести пока не удаётся.

[Вячеслав]

А это не FAT случаем ? А то тама вееесело было со временем модификации файла - 5 бит на секунды => считаем каждую вторую

[Dendy]

Есть весёльІе случаи с компиляцией фантастических исходников из будущего. Но тут еффект бьІл бьІ обратньІй: сколько ни собирай - время зависимостей будет больше и make честно ребилдит всё подряд. Ибо для него етот модерн всегда новее текущего времени.

[Tonal]

А это не FAT случаем ?

Издеваешься? ;-)

Есть весёльІе случаи с компиляцией фантастических исходников из будущего.

А вот это идея.
Синхронизировали на машинах время, будем смотреть дальше.

[Admin]

я про багу со временем писал уже
и вообшще пользуйте precompiled headers
сильно ускоряет

[Tonal]

Про время - очень похоже.
precompiled headers - это да. Надо. ;-)
Всем спасибо.
Если что ещё проясниться - отпишусь.