Współdzielenie wstępnie skompilowanych nagłówków między projektami w Visual Studio

Mam rozwiązanie z wieloma projektami Visual C++, wszystkie używającymi PCH, ale niektóre mają specjalne przełączniki kompilatora włączone dla konkretnych potrzeb projektu.

Większość z tych projektów ma ten sam zestaw nagłówków w odpowiednich stdafx.h (STL, boost itp.). Zastanawiam się, czy jest możliwe współdzielenie PCH między projektami, tak aby zamiast kompilować każdy PCH dla każdego projektu, mógłbym mieć jeden wspólny PCH, którego większość projektów w rozwiązaniu mogłaby po prostu użyć.

Wydaje się możliwe, aby określ lokalizację PCH jako lokalizację współdzieloną w ustawieniach projektu, więc mam przeczucie, że to może zadziałać. Zakładam również, że wszystkie pliki źródłowe we wszystkich projektach, które używają współdzielonego PCH, musiałyby mieć te same ustawienia kompilatora, w przeciwnym razie kompilator narzekałby na niespójności między PCH a kompilowanym plikiem źródłowym.

Czy ktoś tego próbował? Działa?

Podobne pytanie: czy taki odłamek PCH powinien być zbyt integracyjny, czy też zaszkodziłby ogólnie czas budowy? Na przykład współdzielony PCH może zawierać wiele nagłówków STL, które są powszechnie używane, ale niektóre projecst mogą potrzebować tylko <string> i <vector>. Czy czas zaoszczędzony przez użycie współdzielonego PCH musi zostać zwrócony w późniejszym momencie procesu budowania, gdy optymalizator musiałby wyrzucić wszystkie nieużywane rzeczy zaciągnięte do projektu przez PCH?

Author: Assaf Lavie, 2009-03-14
Source

5 answers

Tak, jest to możliwe i zapewniam cię, że oszczędność czasu jest znacząca. Podczas kompilacji PCH musisz skopiować pliki .pdb i .idb z projektu, który tworzy plik PCH. W moim przypadku mam prosty projekt dwóch plików, który tworzy plik PCH. Nagłówek będzie twoim nagłówkiem PCH, a źródło zostanie poinformowane, aby utworzyć PCH w ustawieniach projektu - jest to podobne do tego, co byś zrobił normalnie w każdym projekcie. Jak wspomniałeś, musisz mieć tę samą kompilację ustawienia dla każdej konfiguracji w przeciwnym razie pojawi się Rozbieżność i kompilator będzie narzekał.

Kopiowanie wyżej wymienionych plików za każdym razem, gdy jest przebudowana lub za każdym razem, gdy PCH jest rekompilowany będzie bolało, więc zautomatyzujemy to. Aby zautomatyzować kopiowanie, wykonaj Zdarzenie pre-build, w którym wyżej wymienione pliki zostaną skopiowane do odpowiedniego katalogu. Na przykład, jeśli kompilujesz Debug i Release Kompilacje twojego PCH, skopiuj pliki z Debug twojego projektu PCH do projektu zależnego Debug. Więc polecenie copy wyglądałoby tak

Skopiuj PchPath\Debug*.pdb Debug\ / - Y

Zwróć uwagę na /-Y na końcu. Po pierwszej kompilacji każda kolejna kompilacja jest kompilowana stopniowo, dlatego jeśli zastąpisz Pliki ponownie, Visual Studio będzie narzekać na uszkodzone symbole. Jeśli zostaną uszkodzone, zawsze możesz wykonać przebudowę, która ponownie skopiuje pliki (tym razem nie pominie ich, ponieważ już nie istnieją - cleanup usuwa pliki).

Mam nadzieję, że to pomoże. Zajęło mi to sporo czasu, ale było warto. Mam kilka projektów, które zależą od jednego dużego frameworka, a PCH musi być skompilowany tylko raz. Wszystkie zależne projekty kompilują się teraz bardzo szybko.

EDIT: wraz z kilkoma innymi osobami testowałem to pod VS2010 i VS2012 i wygląda na to, że działa poprawnie.

 21
Author: Samaursa,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-10-31 21:31:45

Chociaż jest to stare pytanie, chcę dać nową odpowiedź, która działa w Visual Studio 2017 i nie wymaga kopiowania. Jedyna wada: Edycja i kontynuacja już nie działa.

Zasadniczo musisz utworzyć nowy projekt dla wstępnie skompilowanego nagłówka i od niego zależą wszystkie inne projekty. Oto co zrobiłem:

Krok po kroku:

  1. Utwórz nowy projekt z rozwiązaniem zawierającym nagłówek (o nazwie pch.h od hereon) oraz jedną linię cpp plik zawierający pch.h. projekt powinien utworzyć statyczny lib. Ustaw nowy projekt, aby utworzyć wstępnie skompilowany nagłówek. Plik wyjściowy musi być dostępny dla wszystkich projektów. dla mnie to względne do IntDir, ale dla ustawień domyślnych może być względne do $(SolutionDir). Projekt pch musi mieć tylko definiuje wszystkie inne projekty mają też.

    ustawienia projektu pch

  2. Czy wszystkie inne projekty zależą od tego nowego projektu. W przeciwnym razie zlecenie budowy może być źle.

    referencje projektu

  3. Skonfiguruj wszystkie inne projekty, aby używały pch.H. zobacz, jak parametry pliku wyjściowego są takie same jak w projekcie pch. Dodatkowe katalogi include również muszą wskazywać na pch.katalog H. Opcjonalnie możesz wymusić dołączenie pliku pch do każdego cpp (lub dołączenie go ręcznie w pierwszej linii KAŻDEGO pliku cpp).

    pch include include

    1. konfiguracja wszystkich projektów (w tym pch projekt), aby użyć tego samego pliku symbolu kompilatora(plik symbolu linkera nie jest naruszony). Ponownie, w moim przykładzie jest to OutDir, ale w Twoim rozwiązaniu może się to różnić. Musi wskazywać na ten sam plik na dysku. Format informacji o debugowaniu musi być ustawiony na C7( zobacz zrzut ekranu powyżej), w przeciwnym razie Visual Studio nie będzie w stanie kompilować projektów równolegle. pdb

Mam nadzieję, że niczego nie zapomniałem. Dla mojego rozwiązania (130K loc, 160 projektów) prowadzi to do czas kompilacji ~2: 30 min zamiast ~3: 30 min.

 10
Author: Nick Papagiorgio,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-03-13 09:45:53

Wydaje się, że nie jest to możliwe, ponieważ każdy plik źródłowy musi być skompilowany na podstawie tego samego PDB, na podstawie którego został skompilowany PCH. cholera.

 5
Author: Assaf Lavie,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-03-18 19:14:22

Odpowiedź Samaursy zadziałała.

Widziałem też link , który działa (poszukaj odpowiedzi u dołu).

Ten używa copy podczas gdy Reginald używa xcopy (ja wolę xcopy). Tak czy siak, dzięki.to znacznie przyspieszyło moją budowę.

 5
Author: Brad W,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-03-27 19:44:30

Dla mnie to brzmi jak przypadek "malejących powrotów". Załóżmy, że włączenie wspólnych nagłówków bezpośrednio marnuje 1 sekundę na .plik cpp, a każdy cel (DLL / EXE) ma 10 .pliki cpp. Za pomocą a .pch na cel, oszczędzasz 10 sekund na cel. Jeśli cały projekt ma 10 celów, oszczędzasz 1,5 minuty na całej kompilacji, co jest dobre.

Ale redukując go do jednego .pch dla całego projektu, zaoszczędzisz tylko kolejne 9 sekund. Czy warto? Dodatkowy wysiłek (który może być o wiele większy fiddly to set up, being a non-standard configuration unsupported by vs wizards) produkuje tylko 10th zapisywania.

 3
Author: Daniel Earwicker,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-03-14 10:52:21