[QGHG-it-dev-list] CMake
Dušan Cvijetić
dusancvijetic2000 at gmail.com
Wed Nov 30 20:11:45 CET 2022
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 <http://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
> <http://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ipb.ac.rs/pipermail/qghg-it-dev-list/attachments/20221130/d257b27b/attachment-0001.htm>
More information about the QGHG-it-dev-list
mailing list