Garapenean, konpiladoreak aldatzea, moduak eraikitzea, mendekotasun bertsioak, analisi estatikoak egitea, errendimendua neurtzea, estaldura biltzea, dokumentazioa sortzea eta abar gustatzen zait. Eta oso maite dut CMake, nahi dudana egiteko aukera ematen didalako.
Askok errieta egiten diote CMake, eta askotan merezita, baina begiratuz gero, ez dago hain txarra, baina azkenaldian ez da batere gaizki, eta garapenaren norabidea nahiko positiboa da.
Ohar honetan, esan nahi dizut zein erraza den C++ goiburuko liburutegi bat CMake sistema batean antolatzea funtzionaltasun hau lortzeko:
Honek, batez ere, CMake script-ak antolatzeko moduari erreparatuko dio, beraz, zehatz-mehatz aztertuko dira. Gainerako fitxategiak edonork ikus ditzake zuzenean. txantiloi proiektuaren orrian.
Lehenik eta behin, CMake sistemaren nahi duzun bertsioa eskatu behar duzu. CMake garatzen da, komandoen sinadurak aldatzen dira, portaera baldintza desberdinetan. CMake-k bertatik zer nahi dugun berehala ulertu dezan, berehala konpondu behar ditugu gure eskakizunak.
cmake_minimum_required(VERSION 3.13)
Ondoren, gure proiektua adierazten dugu, bere izena, bertsioa, erabilitako hizkuntzak, etab. ΠΊΠΎΠΌΠ°Π½Π΄Ρ project).
Kasu honetan, zehaztu hizkuntza CXX (horrek C++ esan nahi du), CMake-k C konpilatzaile bat bilatzeko trabarik izan ez dezan (lehenespenez, bi hizkuntza sartzen dira CMake-n: C eta C++).
project(Mylib VERSION 1.0 LANGUAGES CXX)
Hemen berehala egiaztatu dezakezu gure proiektua azpiproiektu gisa beste proiektu batean sartuta dagoen. Horrek asko lagunduko du etorkizunean.
Lehenengo aukera da MYLIB_TESTING - unitate-probak desgaitzeko. Baliteke hori beharrezkoa izatea probetan dena ondo dagoela ziur baldin bagara, eta, adibidez, gure proiektua instalatu edo paketatu nahi badugu. Edo gure proiektua azpiproiektu gisa sartzen da; kasu honetan, gure proiektuaren erabiltzaileari ez zaio interesatzen gure probak egitea. Ez dituzu erabiltzen dituzun menpekotasunak probatzen, ezta?
Horrez gain, aparteko aukera bat egingo dugu MYLIB_COVERAGE kode estaldura probekin neurtzeko, baina tresna osagarriak beharko ditu, beraz, esplizituki gaitu beharko duzu.
Jakina, programatzaile politak gara, beraz, konpiladorearen konpilazio garaiko diagnostikoen maila maximoa nahi dugu. Sagu bakar bat ere ez da igaroko.
Gure liburutegia goiburuko fitxategiez bakarrik dago osatuta, hau da, ez dugu inolako irteerarik liburutegi estatiko edo dinamiko moduan. Bestalde, gure liburutegia kanpotik erabiltzeko, instalatu behar duzu, sisteman aurkitu eta zure proiektura konektatu eta aldi berean goiburu hauek ere bai. gisa, ziurrenik, propietate gehigarri batzuk.
Horretarako, interfaze-liburutegi bat sortzen dugu.
add_library(mylib INTERFACE)
Goiburuak gure interfazearen liburutegira lotzen ditugu.
CMake-ren erabilera modernoak, modan eta gazteak esan nahi du goiburuak, propietateak, etab. helburu bakar baten bidez transmititzen da. Beraz, nahikoa da esatea target_link_libraries(target PRIVATE dependency), eta xedearekin lotutako goiburu guztiak dependency, xedeari dagozkion iturrietarako eskuragarri egongo da target. Eta ez duzu beharrik [target_]include_directories. Hau behean erakutsiko da analizatzerakoan Unitate-probetarako CMake scripta.
Komando honek behar ditugun goiburuak gure interfaze liburutegiarekin lotzen ditu, eta gure liburutegia CMake hierarkia bereko edozein helbururekin konektatuta badago, direktorioko goiburuak harekin lotuko dira. ${CMAKE_CURRENT_SOURCE_DIR}/include, eta gure liburutegia sisteman instalatuta badago eta komandoa erabiliz beste proiektu batera konektatuta badago find_package, orduan direktorioko goiburuak harekin lotuko dira include instalazio direktorioari dagokionez.
Ezarri hizkuntza estandarra. Noski, azkena. Aldi berean, estandarra sartzeaz gain, gure liburutegia erabiliko dutenei ere banatzen diegu. Hau multzoko propietateak kategoria bat izatea lortzen da INTERFACE (Ikus target_compile_features komandoa).
Gure liburutegirako alias bat lortzen dugu. Eta edertasunagatik, "namespace" berezi batean egongo da. Hau erabilgarria izango da gure liburutegian modulu desberdinak agertzen direnean, eta elkarrengandik independentean konektatzera joaten garenean. Bustan bezala, adibidez.
Gure goiburuak sisteman instalatzen. Hemen dena sinplea da. Goiburu guztiak dituen karpetak direktorioa sartu behar duela esaten dugu include instalazioaren kokapenari dagokionez.
Ondoren, eraikitze-sistemari hirugarrenen proiektuetan komandoari dei egin ahal izan nahi diogula esaten diogu find_package(Mylib) eta helburu bat lortu Mylib::mylib.
Honela ulertu behar da ondorengo doinua. Alboko proiektu batean komandoari deitzen diogu find_package(Mylib 1.2.3 REQUIRED), eta, aldi berean, instalatutako liburutegiaren benetako bertsioa bertsioarekin bateraezina izango da 1.2.3, CMake-k automatikoki errore bat sortuko du. Hau da, ez duzu bertsioen jarraipena eskuz egin beharko.
Probak esplizituki desgaitzen badira dagokion aukera edo gure proiektua azpiproiektu bat da, hau da, beste CMake proiektu batera konektatuta dago komandoa erabiliz add_subdirectory, ez gara hierarkian beherago joaten, eta probak sortzeko eta exekutatzeko komandoak deskribatzen dituen scripta ez da abiarazten.
Lehenik eta behin, nahi duzun proba-esparrua duen pakete bat aurkituko dugu (ordeztu zure gogokoena).
find_package(doctest 2.3.3 REQUIRED)
Testekin gure fitxategi exekutagarria sortzen dugu. Normalean, zuzenean bitar exekutagarrira, funtzioa egongo den fitxategia bakarrik gehitzen dut main.
add_executable(mylib-unit-tests test_main.cpp)
Eta probak berak deskribatzen diren fitxategiak, geroago gehitzen ditut. Baina ez da beharrezkoa hori egitea.
Menpekotasunak lotzen ditugu. Kontuan izan behar genituen CMake helburuak bakarrik erantsi genituela gure bitarrari, eta ez genuela komandoari deitu target_include_directories. Test-esparruko goiburuak eta gure Mylib::mylib, baita eraikitzeko aukerak ere (gure kasuan, C++ hizkuntza estandarra) helburu hauekin batera arakatu ziren.
Azkenik, helburu finko bat sortzen dugu, zeinaren "eraiketa" probak exekutatzen direnen baliokidea den, eta helburu hau lehenetsitako eraikuntzara gehitzen dugu (hau atributuaren ardura da. ALL). Horrek esan nahi du lehenetsitako eraikuntzak probak abiaraziko dituela, hots, ez ditugula exekutatzen ahaztuko.
add_custom_target(check ALL COMMAND mylib-unit-tests)
Ondoren, aktibatu kodea estalduraren neurketa, dagokion aukera ezarrita badago. Ez naiz xehetasunetan sartuko, estaldura neurtzeko tresnarekin lotuta baitaude CMakerekin baino. Garrantzitsua da soilik emaitzek helburu bat sortuko dutela coverage, eta horrekin komenigarria da estaldura neurtzen hastea.
Ondoren, hizkuntza duen aldagaia erabiltzaileak ezartzen duen egiaztatuko dugu. Bai bada, orduan ez dugu ukitzen, ez bada, errusiera hartzen dugu. Ondoren, Doxygen sistemaren fitxategiak konfiguratuko ditugu. Beharrezko aldagai guztiak, hizkuntza barne, horra iristen dira konfigurazio prozesuan (ikus. ΠΊΠΎΠΌΠ°Π½Π΄Ρ configure_file).
Ondoren, helburu bat sortzen dugu doc, dokumentazioa sortzen hasiko dena. Dokumentazioa sortzea garapen-prozesuan beharrik handiena ez denez, xedea ez da lehenespenez sartuko, esplizituki exekutatu beharko da.
if (Doxygen_FOUND)
if (NOT MYLIB_DOXYGEN_LANGUAGE)
set(MYLIB_DOXYGEN_LANGUAGE Russian)
endif()
message(STATUS "Doxygen documentation will be generated in ${MYLIB_DOXYGEN_LANGUAGE}")
configure_file(Doxyfile.in Doxyfile)
add_custom_target(doc COMMAND ${DOXYGEN_EXECUTABLE} ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile)
endif ()
Hemen hirugarren Python aurkituko dugu eta helburu bat sortuko dugu wandbox, zerbitzuaren APIari dagokion eskaera sortzen duena Makila-kutxa, eta bidaltzen du. Erantzun gisa, amaitutako sandboxerako esteka bat dator.
Unitate-probaren eraikuntza eta helburua desaktibatzeko aukera eskaintzen du check. Ondorioz, proben bidezko kodea estaldura neurtzea desaktibatu egiten da (ikus MYLIB_COVERAGE).
Gainera, probak automatikoki desgaitzen dira proiektua beste proiektu batera konektatzen bada komandoa erabiliz azpiproiektu gisa add_subdirectory.
Izan ere, CMake 3.13 bertsioa laguntza honetan deskribatutako kontsolaren komando batzuk exekutatzeko soilik behar da. CMake scripten sintaxiaren ikuspuntutik, 3.8 bertsioa nahikoa da belaunaldiari beste modu batzuetara deitzen bazaio.
CMake oso sistema indartsua eta malgua da, eta gustu eta kolore guztietarako funtzionalitateak ezartzeko aukera ematen du. Eta, zenbaitetan sintaxiak asko uzten badu ere, deabrua oraindik ez da margotua bezain ikaragarria. Erabili CMake build sistema gizartearen eta osasunaren mesederako.