[QGHG-it-dev-list] CMake
Nenad Korolija
nenadko at gmail.com
Wed Nov 30 14:55:59 CET 2022
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ipb.ac.rs/pipermail/qghg-it-dev-list/attachments/20221130/5fca2332/attachment.htm>
More information about the QGHG-it-dev-list
mailing list