System budowania C++ generujący Makefile

0

Witajcie,

Teraz używam CMake w CLion, ale nie pasuje mi ten język skryptowy tego generatora. Wolałbym coś jak Maven albo reguły budowania w JSON chociaż. Niby da się używać Gradle z C++, ale na necie nie za bardzo coś znalazłem, a poza tym CLion indeksuje tylko pliki zawarte w Makefile, więc lepiej by było jakiś generator do Makefile mieć. Ważne też, żeby w projekcie mógłby być jeden główny plik budujący i możliwość zaincludowania plików od osobnych binarek, w jednym projekcie mam dwie binarki i jeden lib dynamiczny używany z tych binarek, a binarki dodam z czasem. Czy zna ktoś taki system budowania i używał może kiedyś?

1

więc lepiej by było jakiś generator do Makefile mieć

Tylko po co?
Dobrze napisany makefile to jak plik projektu w IDE.
A do kompilacji wolę jak idzie to co jawnie do makefile'a dodam, a nie że coś mi bierze z automatu *.cpp i z tego generuje makefile'a.

0

Pisanie makefile dla Win i Lin osobno, podziękuję. Do Makefile bo na jeego podstawie moje IDE indeksuje pliki. Jeszcze pomyśle nad wyborem Gradle, ale niestety IDE przestanie indeksować i może być konieczna zmiana IDE. Jeszcze pomyślę.

1

więc lepiej by było jakiś generator do Makefile mieć

No cmake właśnie jest jakiegoś rodzaju "generatorem" Makefile. Dodatkowo jest cross-platformowy, na windowsie generuje pliczki do solucji visualowej. Nie narzekaj tylko nauczy się cmake. Szukanie alternatyw dla cmake, qmake, Makefile czy tego visualowego czegoś jest głupie.

1

Wydaje mi się, że nie rozumiem w czym problem.

bajos napisał(a):

Witajcie,
Ważne też, żeby w projekcie mógłby być jeden główny plik budujący i możliwość zaincludowania plików od osobnych binarek

Łatwe z CMake, w dużym uproszczeniu jeden główny CMakeList używający ADD_SUBDIRECTORY wskazujący na katalogi z kolejnymi CMakeList z konkretnymi zasadami budowania. Ale to pewnie wiesz, bo gdziesz po drodze piszesz, że znasz i używasz CMake, także w czym problem? Używaliśmy w projekcie w pracy gradle z pluginem C++ i wróciliśmy do cmake. IMHO jedyną prawdziwą przewagą gradle'a jest łatwość z jaką radzi sobie ze ściąganiem zależności z artifactory, repo mavena czy innych, co czyni go naprawde fajnym systemem budowania dla javy. Do C++ jednak brak prawdziwego wsparcia przez IDE boli i to mocno.

Swoją drogą, jestem rozczarowany jak CLion pracuje z cmake, jest to dalekie od tego jak chociażby QtCreator pracuje ze swoimi plikami projektu, o Visualu w ogóle nie wspominając. W QtCreatorze szkielet projektu złożony z podprojektów możesz sobie spokojnie wyklikać, potem dodajesz tylko ścieżki do libek i inkludów i działa. W CLion pewnie jestem ślepy i nie znalazłem guziczków, ale najpierw musiałem napisać cmake'a żeby CLion skumał jaki projekt chce mieć, a potem jeszcze i tak musiałem się naklikać żeby to wszystko debugować.

0

Problem w tym, że każdy includowany plik cmake pracuje w tym samym środowisku, znaczy zmienne nie są w osobnym namespace tylko są globalne, jeśli zmieniam flagi do linkera czy kompilatora to sa stosowane do wszystkich targetów, flagi nie są crossplatformowe tylko musze rozpoznać czy gcc czy msvc, chodzi o coś takiego jak AdressSanitiser albo definicja preprocesora albo ogólnie jakiekolwiek inne flagi, dało by się to zrobić lepiej według mnie.

1

Przeniesione z komentarzy.

@several, jeśli użyję tego add_subdirectory(...) to będę mógł mieć oddzielne flagi kompilarota/linkera do każdego podprojektu?

Tak. Ja zazwyczaj robię coś takiego, że w głównym cmakelist ustawiam sobie jakieś ogólne/typowe flagi a w podprojektach sobie je rozszerzam, czyli w głównym coś takiego:

SET(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${COMMON_LINKER_FLAGS}")
SET(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS} ${COMMON_LINKER_FLAGS}")
SET(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} ${COMMON_LINKER_FLAGS}")

A potem w libce jak potrzebuje coś zmienić:

SET(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Xlinker -Bsymbolic")

Gdzie zmienna CMAKE_SHARED_LINKER_FLAGS jest zdefiniowana w głównym cmakelist.

Disclaimer
Nie napisałem na tyle dużo cmake'ów, żeby czuć się w nim jakoś specjalnie pewnie, albo twierdzić, że moje podejście jest tym najtrafniejszym, ale powyższe działało dla mnie ;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1