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

Pracuję nad projektem C ++ open source, dla kodu, który kompiluje się w systemach Linux i Windows. Używam CMake do tworzenia kodu w systemie Linux. Ze względów politycznych i ułatwienia konfiguracji muszę trzymać się plików / edytora projektów Visual Studio w systemie Windows (nie mogę na przykład przełączyć się na Code :: Blocks ). Widzę instrukcje generowania plików Visual Studio przy użyciu CMake, jak tutaj .

Czy wcześniej używałeś CMake do generowania plików programu Visual Studio? Jakie masz doświadczenia? Załóżmy, że chcę dodać nowy plik do mojego projektu. Jaki jest przepływ pracy w tym celu?

CMake jest do tego całkiem niezły. Kluczową kwestią było to, że wszyscy po stronie Windowsa musieli pamiętać o uruchomieniu CMake przed załadowaniem rozwiązania, a każdy po stronie naszego Maca musiałby pamiętać, aby go uruchomić przed utworzeniem.

Najtrudniej było jako programista Windows, upewniając się, że zmiany strukturalne znajdują się w pliku cmakelist.txt, a nie w rozwiązaniu lub plikach projektu, ponieważ te zmiany prawdopodobnie zostaną utracone, a nawet jeśli nie zostaną utracone, nie zostaną przeniesione na stronę Maca, która również ich potrzebowali, a faceci z komputerów Mac musieliby pamiętać, aby nie modyfikować pliku make z tych samych powodów.

Wymaga tylko trochę namysłu i cierpliwości, ale na początku będą błędy. Ale jeśli korzystasz z ciągłej integracji po obu stronach, to wcześnie się to wytrząśnie i ludzie w końcu wejdą w nawyk.

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

cmake -G "Visual Studio 10"

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

Przenieśliśmy łańcuch kompilacji naszego działu do CMake i mieliśmy kilka wewnętrznych problemów, ponieważ inne działy korzystały z naszych plików projektu i były przyzwyczajeni do importowania ich do swoich rozwiązań. Mieliśmy również skargi na to, że CMake nie jest w pełni zintegrowany z menedżerem projektów / rozwiązań Visual Studio, więc pliki musiały być dodawane ręcznie do CMakeLists.txt; była to główna przerwa w przepływie pracy, do którego ludzie byli przyzwyczajeni.

Ale ogólnie było to dość płynne przejście. Jesteśmy bardzo szczęśliwi, ponieważ nie musimy już zajmować się plikami projektu.

Konkretny proces dodawania nowego pliku do projektu jest naprawdę prosty:

1. Utwórz plik, upewnij się, że znajduje się we właściwym miejscu.
2. Dodaj plik do CMakeLists.txt.
3. Budować.

CMake 2.6 automatycznie uruchamia się ponownie, jeśli jakiekolwiek pliki CMakeLists.txt ulegną zmianie (i (częściowo) automatycznie przeładuje rozwiązanie / projekty).

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

Jak mówi Alex, działa bardzo dobrze. Jedyną trudną częścią jest pamiętanie o wprowadzaniu zmian w plikach cmake, a nie z poziomu programu Visual Studio. Tak więc na wszystkich platformach przepływ pracy jest podobny do tego, gdy 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 czegokolwiek w tym rodzaju, więc nie martwiłbym się zbytnio.

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

Dodawanie i usuwanie plików źródłowych to tylko kwestia modyfikacji tego, CMakeLists.txtktóry ma listę plików źródłowych i ponownego wygenerowania projektów / rozwiązań. Istnieje nawet funkcja globbingu, która pozwala znaleźć wszystkie źródła w katalogu (chociaż należy jej używać ostrożnie).

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

CMake i Visual Studio

CMake może wygenerować naprawdę fajne Visual Studio .projs/ .slns, ale zawsze istnieje problem z koniecznością modyfikacji .cmakeplików zamiast .proj/ .sln. Jak to jest teraz, mamy do czynienia z tym w następujący sposób:

1. Wszystkie pliki źródłowe przechodzą do, /srca pliki widoczne w programie Visual Studio są po prostu „linkami” do nich zdefiniowanymi w .filter.
2. Programista dodaje / usuwa pliki pamiętając o pracy w zdefiniowanym /srckatalogu, a nie w katalogu domyślnego projektu.
3. Kiedy skończy, uruchamia skrypt, który „odświeża” odpowiednie .cmakepliki.
4. Sprawdza, czy kod można zbudować w odtworzonym środowisku.
5. Zatwierdza kod.

Na początku trochę się baliśmy, jak to się potoczy, ale workflow działa naprawdę dobrze i dzięki ładnemu diffowi widocznemu przed każdym zatwierdzeniem, każdy może łatwo sprawdzić, czy jego zmiany zostały poprawnie zmapowane w .cmakeplikach.

Jeszcze jedną ważną rzeczą, o której należy wiedzieć, jest brak wsparcia ( afaik ) dla „konfiguracji rozwiązań” w CMake. W obecnej postaci musisz wygenerować dwa katalogi z projektami / rozwiązaniami - po jednym dla każdego typu kompilacji (debug, wydanie itp.). Nie ma bezpośredniego wsparcia dla bardziej wyrafinowanych funkcji - innymi słowy: przełączanie się między konfiguracjami nie daje tego, czego można się spodziewać.

Wiele świetnych odpowiedzi tutaj, ale mogą zostać zastąpione przez tę obsługę CMake w programie Visual Studio (5 października 2016 r.)

Rozpocząłem 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ć programu Visual Studio do programowania, a obecnie obsługiwany jest tylko język C ++.

Główną zaletą w porównaniu z innymi systemami make jest to, że możesz faktycznie debugować swój skrypt, ponieważ jest on oparty na C #.

Jeśli nie jesteś zaznajomiony z syncProj, możesz po prostu przekonwertować swoje rozwiązanie / projekt do skryptu .cs i kontynuować dalszy rozwój od tego momentu.

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