[QGHG-it-dev-list] CMake

Wed Nov 30 22:30:01 CET 2022

> želite da svaki segment našeg projekta (testovi, GUI i biblioteka) ima zaseban CMakeLists, kao da je sasvim odvojeni projekat, umesto da postoji ovakvo objedinjeno kompajliranje?

Dabome, upravo je poenta da gui, test i library budu potpuno odvojeni projekti, koji se zasebno kompajliraju (pri cemu naravno gui i test moraju da linkuju binarnu verziju biblioteke i da imaju pristup njenim header fajlovima).

Zamisli ovako --- ti pises neki program u C-u, i treba da izracunas sin(x) negde u svom programu. Ono sto ti je dovoljno da uradis je da u svojoj main() f-ji kazes #include "math.h", i da pozoves f-ju sin(x). Kad kompajliras svoj program, kompajler ce da pronadje taj include-fajl, i da linkuje sistemsku biblioteku sa matematickim funkcijama za tvoj izvrsni fajl. Ono sto sigurno *ne radis* u takvoj situaciji je da kompajliras biblioteku matematickih funkcija --- to vec ima negde gotovo u operativnom sistemu (unutar glibc ili gde vec...), i za to po pravilu cak uopste nemas source kod na svojoj masini (i ne treba ti, dovoljan ti je header fajl).

Na potpuno isti nacin moze da radi npr. Jaroslav --- on pise gui, i uopste ga ne zanima kompajliranje biblioteke. On hoce u svoj kod da stavi #include "triangulator.hpp" i da kompajlira gui, a biblioteku vec ima gotovu u binarnom obliku, i samo treba da je linkuje. Dakle cmake koji kompajlira gui treba da bude podesen da tako radi. I naravno, potpuno ista prica i za test.cpp.

A sa druge strane, ti i ja npr. razvijamo samu biblioteku. Mi treba da kompajliramo biblioteku i da okacimo njen binary fajl na web sajt, odakle ce razni korisnici da ga skidaju i koriste. Ti i ja nemamo pojma ko sve to koristi, i na koji nacin. Formalno gledano, ti i ja ne znamo da npr. Jaroslav pravi gui, ili da Nenad pise test.cpp. Znaci cmake za biblioteku uopste ne sme da zna nista ni o gui-ju, ni o testovima, niti o cemu trecem. On samo treba da kompajlira biblioteku, i gotovo.

Inace, to sto se i biblioteka i testovi i gui nalaze u istom repository-ju na GitHub-u je samo sticaj okolnosti, jer nam je tako zgodno, i jer mene mrzi da pravim tri razlicita repository-ja za njih. Ali logicki su to tri potpuno odvojena projekta, i treba da se kompajliraju nezavisno jedan od drugog.

> Je li tu cilj obezbediti da se sama biblioteka ne mora svaki put kompajlirati?

Da, tehnicki gledano, to je cilj. Pritom, to nije zato da bismo stedeli resurse i brzinu kompajliranja, nego je poenta u tome da se (i mentalno i tehnicki) "odvoji posao" koji radi biblioteka od "poslova" koje rade test, gui, i stagod trece. To moramo da drzimo tako strukturno odvojeno, inace cemo kasnije doci u iskusenje da pocnemo da mesamo kod biblioteke sa kodom za gui ili za test, sto bi definitivno vodilo u probleme. Zato ovoliko insistiram na celoj ovoj stvari oko kompajliranja. ;-)

Nadam se da je sad jasnije kako zelim da organizujes cmake? Dakle tri potpuno nezavisna projekta, nezavisni CMakeLists.txt u sva tri direktorijuma, svaki se kompajlira za sebe, itd.

Btw, da ne zaboravim --- direktorijum third_party_software je deo koda biblioteke (nema veze sa testovima i gui-jem), pa bi mozda bilo bolje da ga stavis da stoji unutar library direktorijuma, zajedno sa include i src. Kasnije ce mozda gui i test da imaju svoje third-party dodatke, pa da se ne mesaju jedni sa drugima.

:-)
Marko

Dr. Marko Vojinovic
Group for Gravitation, Particles and Fields
Institute of Physics
University of Belgrade
======================
home page: www.markovojinovic.com
e-mail:    vmarko at ipb.ac.rs

On Wed, 30 Nov 2022, Dušan Cvijetić wrote:

> 
> Pozdrav,
> 
> Trenutno je cmake organizovan tako da postoji glavni CMakeLists.txt na vrhu, koji opciono poziva razne funkcionalnosti naše biblioteke (GUI i testiranje), a samu biblioteku uvek
> kompajlira. To je jedini princip koji sam do sad video da se koristi, pa je i jedini za koji znam, i zato sam počeo tako da pripremam CMake. Ukoliko sam Vas dobro razumeo, želite da
> svaki segment našeg projekta (testovi, GUI i biblioteka) ima zaseban CMakeLists, kao da je sasvim odvojeni projekat, umesto da postoji ovakvo objedinjeno kompajliranje? Je li tu cilj
> obezbediti da se sama biblioteka ne mora svaki put kompajlirati?
> 
> Pozdravi,
> Dušan
> 
> 
> 
> On 30/11/2022 14:55, Nenad Korolija wrote:
>       Zdravo,
> 
> U potpunosti se slazem. Koliko vidim, cmake moze da radi git pull. Nekada nije... Meni u svakom slucaju nije problem sve da radim skriptom, ali bi slucaj provere i git pull bio
> koristan za razne scenarije, npr. random korisnik vidi sta su drugi random korisnici radili i okacili kao primer na internet, proba, kad ono... Nema odgovarajucu verziju koda...
> 
> Vidimo se,
> Nenad
> 
> On Wed, Nov 30, 2022 at 2:05 AM Marko Vojinovic <vmarko at ipb.ac.rs> wrote:
>
>       Pozdrav Dusane,
>
>       Pogledao sam CMakeLists.txt koji si napravio, pa evo na brzinu tri komentara za organizaciju cmake...
>
>       (1) Nenad je potpuno u pravu za imena direktorijuma, preimenuj ih u include i src. :-)
>
>       (2) Verzija Triangulatora sigurno jos nije 1.0, stavi npr 0.5 ili nesto slicno.
>
>       (3) Gui ne treba da posmatras kao neki modul koji biblioteka moze ili ne mora da koristi. Naprotiv, gui je taj koji treba da koristi biblioteku. Drugim recima,
>       biblioteka se uvek kompajlira bez gui-ja, a gui treba da zamisljas kao standalone executable, slicno kao test.cpp. Tako da ovo
>
>           option(TRIANG_USE_GUI "Compile and use Qt GUI for triangulator." OFF)
>
>       ja ne bih stavljao kao opciju biblioteke, jer biblioteka treba uvek da se kompajlira bez gui-ja. A za gui (pa cak i za test.cpp) bi mogao da napravis zasebne
>       cmakelists.txt, koji ce da kompajliraju samo gui (odnosno samo test.cpp), i eventualno kao opciju da pre toga pozovu cmake koji ce da kompajlira najnoviju verziju
>       biblioteke, i onda je linkuju. A cmake za biblioteku treba da napravi samo biblioteku, i nista vise sa njom.
>
>       Znaci organizuj cmake da pokrije otprilike sledece zamisljene slucajeve:
>
>       * Slucaj 1 --- angazujem Nenada da pise test.cpp kao svoj projekt, i dam mu gotovu prekomajliranu biblioteku (u binarnom formatu za njegov OS) koju treba da testira.
>       Nenad ne zna nista o source kodu biblioteke, ima samo gotov .a ili .dll fajl, i potrebne include-fajlove. Napisi cmake za njegov test.cpp.
>
>       * Slucaj 2 --- angazujem Jaroslava da pravi gui, i dam mu gotovu prekompajliranu biblioteku i include-fajove. Jaroslav takodje ne zna nista o source-u za biblioteku.
>       Napisi cmake koji ce da kompajlira njegov gui.
>
>       * Slucaj 3 --- angazujem tebe da pises rutine u biblioteci, pri cemu ti ne znas da postoje ni gui, ni test.cpp, niti sta trece sto neko negde jos programira. Napisi
>       cmake koji ce da kompajlira biblioteku, tj. da napravi .a ili .dll fajl (koji cu posle da posaljem ovoj dvojici u gornjim slucajevima).
>
>       * Slucaj 4 --- Nenad shvati da mu treba neka rutina iz verzije v2.4 biblioteke, ali on nazalost ima .dll samo od stare verzije v1.6. Ako je izvodljivo, napisi nov
>       cmake za njegov test.cpp, koji ce da proveri da li postoji novija verzija biblioteke, zatim da ode na GitHub, svuce source za najnoviju biblioteku v3.1 na Nenadov
>       racunar, kompajlira je kao u slucaju 3 da dobije najnoviji .dll, pa nakon toga da pozove Nenadov stari cmake (iz slucaja 1) da kompajlira njegov test.cpp.
> 
>
>       Eto tako bih ja voleo da to radi. Pritom, ne znam da li cmake ima funkcionalnost za sve ovo iz slucaja 4 (mozda za to postoji neki drugi alat, ili Nenad moze rucno da
>       ode na GitHub i kompajlira biblioteku kao u slucaju 3), ali ove slucajeve definitivno treba da koristis kao misaone modele kad konstruises cmakelists.txt. ;-)
>
>       :-)
>       Marko
> 
>
>       Dr. Marko Vojinovic
>       Group for Gravitation, Particles and Fields
>       Institute of Physics
>       University of Belgrade
>       ======================
>       home page: www.markovojinovic.com
>       e-mail:    vmarko at ipb.ac.rs
> 
> 
>
>       On Tue, 29 Nov 2022, Nenad Korolija wrote:
>
>       > Odlicno!
>       > Samo bih headers i implementation pre zvao include i src (AKKO nema razloga za bas headers i implementation). Rekao bih da je to neki standard.
>       >
>       > Pozdrav,
>       > Nenad
>       >
>       > On Mon, Nov 28, 2022 at 4:40 PM Marko Vojinovic <vmarko at ipb.ac.rs> wrote:
>       >
>       >       Pozdrav Dusane,
>       >
>       >       Slazem se, moze svaki test da ima svoj .cpp fajl, mozemo tako da ih pravimo.
>       >
>       >       Takodje se slazem za reorganizaciju koda po folderima (vec neko vreme razmisljam da to treba da se uradi). Samo obrati paznju na sledece detalje:
>       >
>       >       (1) Organizuj putanje inteligentno --- svi implementation fajlovi include-uju "triangulator.hpp", koji zatim rekurzivno include-uje sve ostale .hpp fajlove.
>       Namesti to sve tako da kompajler moze
>       >       bez problema da nadje sve fajlove koji mu trebaju. Imaj u vidu da ce kasnije i QtCreator i VS da traze te iste fajlove za kompajliranje gui-ja.
>       >
>       >       (2) Mozes unutar "library" da dodas i cetvrti direktorijum "obj", u koji ce kompajler da stavlja binary fajlove --- object-fajlove (.o), staticku biblioteku
>       (.a), i sve izvrsne fajlove. To je
>       >       uvek pametno odvojiti od source-a (headers, implementatation, tests). Git naravno treba da ignorise taj direktorijum.
>       >
>       >       (3) Nemoj da pravis nikakvu hijerarhiju unutar gui direktorijuma --- i QtCreator i VS vole neke svoje hijerarhije, i meni je najlakse da tu unutra prosto
>       copy-paste-ujem ono sto mi posalje
>       >       Jaroslav. A njemu je izgleda najlakse da mu svi source fajlovi za gui stoje u jednom direktorijumu. Namesticemo neku hijerarhiju ako Jaroslav bude trazio,
>       zasad neka stoje svi gui-fajlovi ovako.
>       >
>       >       (4) Direktorijum 3rd_party isto neka ostane --- hocu da imam u repository-ju staticku kopiju kompletnog koda koji je potreban za projekt, i kompajler treba da
>       gleda samo u taj kod, nigde napolje.
>       >       Ako kasnije odlucimo da 3rd-party softver update-ujemo novijim verzijama ili slicno, to mozemo da uradimo rucno (nikakva automatska azuriranja i download
>       tudjeg koda). Filozofija je da kompletan
>       >       kod za projekt (i nas i tudj kod) bude uvek na *jednom* mestu --- u nasem repository-ju, i pod nasom kontrolom, ne zelim da postupak kompajliranja na bilo koji
>       nacin zavisi od tudjih
>       >       repository-ja ili sl.
>       >
>       >       To su otprilike neke sugestije. Ostalo sve namesti kako mislis da je pametno, pa ako bude potrebe kasnije mozemo da stelujemo i doterujemo celu strukturu
>       dodatno.
>       >
>       >       :-)
>       >       Marko
>       >
>       >
>       >       Dr. Marko Vojinovic
>       >       Group for Gravitation, Particles and Fields
>       >       Institute of Physics
>       >       University of Belgrade
>       >       ======================
>       >       home page: www.markovojinovic.com
>       >       e-mail:    vmarko at ipb.ac.rs
>       >
>       >
>       >
>       >       On Mon, 28 Nov 2022, Dušan Cvijetić wrote:
>       >
>       >       >
>       >       > Pozdrav,
>       >       >
>       >       > Otvaram novu temu za diskusiju o cmake funkcionalnostima. Danas ću započeti sa time, pa će mi trebati verovatno par dana.
>       >       >
>       >       > Što se tiče
>       >       >
>       >       > > Imalo bi smisla da implementiramo raznorazne f-je unutar test.cpp, koje bi testirale raznorazne funkcionalnosti
>       >       >
>       >       > mislim da je bolji način za organizaciju testova takav da svaki test ima svoj ime_testa.cpp fajl, pa da ih onda pozivamo pomoću ctest funkcionalnosti. Tako
>       je preglednije, imamo veću
>       >       > fleksibilnost sa proverama, i ne moramo da brinemo o štampanju rezultata u konzolu u samom testu (ne moramo da pišemo "Prošao test" ili slično u .cpp
>       fajlovima).
>       >       >
>       >       > Što se tiče samog cmake-a, želeo sam da uz CMakeLists napravim reorganizaciju koda po folderima, koja bi izgledala ovako:
>       >       >
>       >       > triangulator
>       >       > |    library
>       >       > |    |    headers
>       >       > |    |    implementation
>       >       > |    |    tests
>       >       > |    gui
>       >       > |    |    headers
>       >       > |    |    implementation
>       >       > |    |    tests
>       >       > |    3rd_party    (proveriću da li je neophodno da zadržimo ovo, možda cmake može sam da klonuje to)
>       >       >
>       >       > Kako vam se to čini?
>       >       >
>       >       > Pozdravi,
>       >       > Dušan
>       >       >
>       >       >
>       >       >--
>       >       QGHG-it-dev-list mailing list
>       >       QGHG-it-dev-list at ipb.ac.rs
>       >       http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
>       >
>       >
>       >--
>       QGHG-it-dev-list mailing list
>       QGHG-it-dev-list at ipb.ac.rs
>       http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> 
> 
> 
>