Kategoria: Bez kategorii

Języki takie jak C i C++ zakładają, że programista wie co robi i pozwalają mu na wiele. Są bardzo konserwatywne w zgłaszaniu błędów i warningów. Nieraz obraca się to przeciwko programiście, dlatego sami aktywujemy dodatkowe flagi warningów podczas kompilacji i używamy różnych narzędzi do analizy kodu.

Ale do narzędzi takich jak cppcheck czy clang-tidy musimy podać te same pliki źródłowe, include, define co w głównym buildzie. Konfiguracja jest dosyć trudna. Na szczęście system budowania może nam w tym pomóc. W końcu posiada wszystkie informacje przekazywane kompilatorowi. Dzisiaj zobaczymy jak skonfigurować analizę statyczną w CMake.

W poprzednim odcinku skonfigurowaliśmy sobie większy projekt. Mieliśmy oddzielne targety na poszczególne podprojekty. Dzięki temu dało się na przykład utworzyć bibliotekę statyczną, czy dodać bibliotekę header only. Dzięki odpowiedniej konfiguracji byliśmy w stanie raz skompilować podprojekt i używać go w wielu targetach. Teraz pójdziemy o krok dalej. Nasze podprojekty będą automatycznie ściągane z własnych repozytoriów.

W przykładzie użyje repo na GitHubie, ale równie dobrze można użyć innych systemów kontroli wersji, serwerów, czy nawet lokalnych plików. Zalety takiego rozwiązania w większych projektach są nieocenione. Po pierwsze możemy sensownie zarządzać aktualizacjami zewnętrznych bibliotek, a po drugie możemy tworzyć własne reużywalne biblioteki z aktualizacjami propagowanymi na wszystkie projekty.

We wcześniejszym artykule pokazałem jak napisać prosty skrypt CMake. Za jego pomocą możemy zrealizować najważniejsze zadania stawiane skryptowi budowania. A więc możemy dodawać pliki źródłowe, headery, flagi kompilacji, czy definicje preprocesora.

Na początek taki skrypt jest jak najbardziej w porządku. Robi to co powinien i pozwala nam oswoić się ze składnią i działaniem CMake. Ale to nie jest najlepszy sposób pisania skryptów CMake i kiedy będziemy chcieli skorzystać z bardziej zaawansowanych opcji – możemy mieć problemy.

Dlatego w dzisiejszym wpisie zobaczymy jak pisać skrypty CMake zgodnie ze sztuką i jakie z tego będziemy mieć korzyści. Dowiemy się też dlaczego w skryptach CMake powinniśmy zawsze korzystać z komend z prefixem target_.