[QGHG-it-dev-list] CMake
Marko Vojinovic
vmarko at ipb.ac.rs
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
>
>
>
>
More information about the QGHG-it-dev-list
mailing list