Używanie CMake do generowania plików projektów Visual Studio C++

Question

Pracuję nad projektem C++ open source, dla kodu, który kompiluje się w systemie Linux i Windows. Używam CMake do budowania kodu w systemie Linux. Ze względu na łatwość programowania i przyczyny polityczne, muszę trzymać się plików/edytorów projektów Visual Studio w systemie Windows (na przykład nie mogę zmienić na Code::Blocks). Widzę instrukcje generowania plików Visual Studio przy użyciu CMake, jako here.

Czy używałeś CMake do generowania plików Visual Studio przed? Jak było twoje doświadczenie? Załóżmy, że chcę dodać nowy plik do mojego projektu. Jaki jest przepływ pracy?

Answer 1

CMake jest w tym całkiem niezły. Kluczową częścią było to, że wszyscy po stronie systemu Windows muszą pamiętać o uruchomieniu CMake przed załadowaniem do rozwiązania, a każdy na naszej stronie Mac musi pamiętać, aby uruchomić go przed wprowadzeniem.

Najtrudniej było, jako programista systemu Windows upewnić się, że zmiany strukturalne były w pliku cmakelist.txt, a nie w plikach rozwiązania lub projektu, ponieważ te zmiany prawdopodobnie zostałyby utracone, a nawet jeśli nie zostały utracone, nie zostałyby przeniesione na strona Mac, która również ich potrzebowała, a faceci Mac musieliby pamiętać, aby nie modyfikować pliku make z tych samych powodów.

To wymaga tylko trochę myślenia i cierpliwości, ale na początku będą błędy. Ale jeśli używasz continuous integration po obu stronach, te zostaną wcześniej wstrząśnięte, a ludzie w końcu dostaną nawyku.

Answer 2

Jak mówi Alex, działa bardzo dobrze. Jedyną trudną częścią jest zapamiętanie wszelkich zmian w plikach cmake, a nie w Visual Studio. Tak więc na wszystkich platformach przepływ pracy jest podobny do tego, jeśli używałeś zwykłych starych plików Makefile.

Ale praca z nim jest dość łatwa i nie miałem problemów z generowaniem przez cmake nieprawidłowych plików lub czymś podobnym, więc nie martwiłbym się zbytnio.

Answer 3

Przenieśliśmy naszą linię produkcyjną naszego działu do CMake, a my mieliśmy kilka wewnętrznych problemów, od innych działów, w których korzystaliśmy z naszych plików projektów i gdzie zwyczajnie importowaliśmy je do swoich rozwiązań. Mieliśmy również kilka skarg na to, że CMake nie jest w pełni zintegrowany z menedżerem projektu/rozwiązania Visual Studio, więc pliki musiały zostać dodane ręcznie do CMakeLists.txt; była to poważna przerwa w przepływie pracy, do której byli przyzwyczajeni ludzie.

Ale generalnie było to dość płynne przejście. Jesteśmy bardzo szczęśliwi, ponieważ nie mamy już do czynienia z plikami projektów.

Beton workflow za dodanie nowego pliku do projektu jest bardzo prosta:

1. Tworzenie pliku, upewnij się, że znajduje się we właściwym miejscu.
2. Dodaj plik do CMakeLists.txt.
3. Kompilacja.

CMake 2.6 automatycznie ponownie się wyświetla, jeśli jakiekolwiek pliki CMakeLists.txt uległy zmianie (i (pół) automatycznie przeładowuje rozwiązanie/projekty).

Pamiętaj, że jeśli robisz kompilacje poza źródłem, musisz uważać, aby nie utworzyć pliku źródłowego w katalogu budowania (ponieważ Visual Studio wie tylko o katalogu kompilacji).

Answer 4

CUpewnij może generować naprawdę piękny Visual Studio .projs/.slns, ale zawsze jest problem z koniecznością zmodyfikowania .cmake plików zamiast .proj/.sln. Jak to jest teraz, mamy do czynienia z tym, co następuje:

1. Wszystkie pliki źródłowe iść do /src i plików widocznych w Visual Studio są tylko „linki” do nich zdefiniowane w .filter.
2. Programista dodaje/usuwa pliki pamiętając, aby pracować na zdefiniowanym katalogu /src, a nie domyślnym projekcie.
3. Kiedy skończy, uruchamia skrypt, który "odświeża" odpowiednie pliki .cmake.
4. Sprawdza, czy kod można zbudować w odtworzonym środowisku.
5. Zatwierdza kod.

Na początku byliśmy trochę boi, jak się okaże, ale workflow działa bardzo dobrze i miły diff widoczne przed każdym popełnienia, każdy może łatwo sprawdzić, czy jego zmiany zostały prawidłowo odwzorowane w .cmake plików.

Jeszcze jedna ważna informacja to brak wsparcia (afaik) dla "Konfiguracji rozwiązań" w CMake. W obecnej wersji musisz wygenerować dwa katalogi z projektami/rozwiązaniami - po jednym dla każdego typu kompilacji (debugowanie, wydanie itp.). Nie ma bezpośredniego wsparcia dla bardziej wyrafinowanych funkcji - innymi słowy: przełączanie między konfiguracjami nie zapewni Ci tego, czego możesz się spodziewać.

Answer 5

Nie jestem pewien, czy to bezpośrednio związane z pytaniem, ale szukałem odpowiedzi na jak generować * .sln z projektów CUpewnij Odkryłam, że można używać czegoś takiego:

cmake -G "Visual Studio 10" 

Przykład generuje potrzebne pliki VS 2010 z pliku wejściowego CMakeLists.txt

Answer 6

CMake bezproblemowo tworzy projekty i rozwiązania Visual Studio. Możesz nawet tworzyć projekty/rozwiązania dla różnych wersji Visual Studio bez wprowadzania jakichkolwiek zmian w plikach CMake.

Dodawanie i usuwanie plików źródłowych to tylko modyfikacja CMakeLists.txt, która ma listę plików źródłowych i regenerację projektów/rozwiązań. Istnieje nawet funkcja globowania, aby znaleźć wszystkie źródła w katalogu (choć należy z niej korzystać ostrożnie).

Poniższy link wyjaśnia bardzo dobrze zachowanie w CMake i Visual Studio.

CMake and Visual Studio

Answer 7

zacząłem mój własny projekt o nazwie syncProj. Dokumentacja/linki do pobrania stąd:

https://docs.google.com/document/d/1C1YrbFUVpTBXajbtrC62aXru2om6dy5rClyknBj5zHU/edit# https://sourceforge.net/projects/syncproj/

Jeśli planujesz używać Visual Studio dla rozwoju, a obecnie tylko C++ jest obsługiwana.

Główną zaletą w porównaniu do innych systemów make jest fakt, że można faktycznie debugować skrypt, ponieważ jest oparty na C#.

Jeśli nie jesteś zaznajomiony z syncProj, możesz po prostu skonwertować swoje rozwiązanie/projekt na skrypt .cs i kontynuować dalsze prace od tego momentu.

W cmake będziesz musiał napisać wszystko od podstaw.

Answer 8

Wiele wspaniałych odpowiedzi tutaj, ale mogą one zostać zastąpione przez niniejszą CMake support in Visual Studio (Oct 5 2016)