Хочу сделать общий на много проектов pch файл (так как, как оказалось, для каждого проекта он генерируется отдельно, а содержимое одинаковое). В pch будут подключаться только стандартные библиотеки вроде stl, boost и т.д.
Сделал специальный проект, состоящий только из stdafx.h / cpp, прописал там инклуды stl/boost — все хорошо, pch генерируется. А вот при попытке подключить этот pch к другому проекту при компиляции этого проекта вылезает такое:
vc100.pdb is not the pdb file that was used when this precompiled header was created, recreate the precompiled header.
vc100.idb is not the idb file that was used when this precompiled header was created, recreate the precompiled header.
Здравствуйте, x-code, Вы писали: XC>Сделал специальный проект, состоящий только из stdafx.h / cpp, прописал там инклуды stl/boost — все хорошо, pch генерируется. А вот при попытке подключить этот pch к другому проекту при компиляции этого проекта вылезает такое:
есть три опция подключения pch
— create pch file
— use pch file
— automatic
догадка моя, что вы используете последнее. оно и само по себе то подглючивает, а в таком случае тем более работать не будет. попробуйте use pch file
Здравствуйте, __kot2, Вы писали:
__>есть три опция подключения pch __>- create pch file __>- use pch file __>- automatic
__>догадка моя, что вы используете последнее. оно и само по себе то подглючивает, а в таком случае тем более работать не будет. попробуйте use pch file
Опции "automatic" нет, есть "not use". А использую я именно use.
The problems described in the link above are real, so we had to find workarounds since suggestion #98646 was postponed:
— Parallel building results in read-locks of the shared pch file.
Our clients have to disable parallel building
— Error with debug builds: error C2859: (...)\vc90.pdb is not the pdb file that was used when this precompiled header was created, recreate the precompiled header.
For this one we had to find a trick : the "Program Database file Name" C++ option of our projects are set to the file name of our precompiled header project ($(IntDir)\mypchprojetname). As a pre-build-step, we copy the .pdb and .idb file from our pch project folder output to the current project folder output:
The reason we do this is because the Program Database File is modified during the build process to include debug info for the compiled files and then can not be shared between projects.
Notice the /D option that will only copy the file when it's newer. If you don't set this option, the project pdb file will be replaced by the one from the pch project when you just link your project, and the debug info from your project sources will be crashed, resulting in the following warning for every source files: myfile.obj : warning LNK4204: '(...)\mypchprojetname.pdb' is missing debugging information for referencing module; linking object as if no debug info.
хотя все это криво, все же pch привязаны по задумке к проекту (то есть у каждого проекта свой pch, потому что свойства проекта типа дефайнов могут быть разные).
вы идете скользкой дорожкой
Здравствуйте, x-code, Вы писали:
XC>И если для msvc не выйдет, может хотя-бы для gcc стоит это сделать? Или там тоже никак?
В сулчае с msvc в лучшем случае может однажды показаться, что все работает. А потом — бабах. В общем, так делать не советуют.
Про gcc врать не буду, сам не пробовал.
Здравствуйте, x-code, Вы писали:
XC>Хочу сделать общий на много проектов pch файл (так как, как оказалось, для каждого проекта он генерируется отдельно, а содержимое одинаковое). В pch будут подключаться только стандартные библиотеки вроде stl, boost и т.д.
Мне сама идея крайне не нравится. Даже если удастся это сделать. В pch подключаются не библиотеки, а хедеры, а что такое стандартные хедеры — бог знает. Понадобится в одном из проектов потом добавить редко используемый хедер из С-шных — последствия не заставят себя ждать.
И для чего ?
Скорость увеличить ? Так pch файлы не часто изменяются.
Здравствуйте, x-code, Вы писали:
XC>Хочу сделать общий на много проектов pch файл (так как, как оказалось, для каждого проекта он генерируется отдельно, а содержимое одинаковое). В pch будут подключаться только стандартные библиотеки вроде stl, boost и т.д.
Немного не о том, но в контексте увеличения скорости сборки тоже может быть интересно...
Решил недавно по быстрому прикрутить precompiled заголовки (не использовались). Чтобы не затрагивать файлы проекта добавил precomipled.h через /FI.
/Yc опция не дружит с /MD, а многопоточная сборка всё таки рулит. Поэтому для проекта ставим /Yu, плюс добавляем пустышку precompiled.cpp с опцией /Yc.
Ну и вроде всё, сначала компилируется pch, а потом уже с /MD всё остальное.
Для gcc всё то же самое, даже проще — добавляем .gch target, натравливаем компилятор непосредственно на precompiled.h, ставим в зависимость от него всё остальное.
Аналогично /FI подключаем precompiled.h через -include. Через зависимость сначала компилируется precompiled.h -> precompiled.gch, а потом уж все его используют.
C gcc получается можно и один gch на несколько проектов сделать.
Ещё можно поиграться со сборкой без использования диска. Поставить, например, ImDisk. Прописать пути сборки относительно переменной окружения, а студию запускать через батник с установкой этой переменной в путь к папке на RAM диске. Чтоб совсем-совсем без диска в этом же батнике переопределить TEMP/TMP, там компилятор всякие временные файлики создаёт. Правда, если SSD используется, выигрыша практически нет.
