[QGHG-it-dev-list] CMake
Dušan Cvijetić
dusancvijetic2000 at gmail.com
Wed Nov 30 21:34:00 CET 2022
Pozdrav,
Mislim da sam shvatio šta ste hteli, i sada je nova verzija
CMakeLists.txt fajlova dostupna na git-u. Ukoliko je potrebno koristiti
prekompajlirane biblioteke, one moraju da se nađu u okviru sledeće
folderske strukture:
triangulator
| precompiled_libs
| | triangulator
| | | Triangulator.a (ili Triangulator.dll)
| | | *.h (svi header-i potrebni za biblioteku)
| | rapidxml (neophodan za Triangulator)
| | | *.h (svi header-i za potrebnu verziju rapidxml-a koju koristi
dati Triangulator.a)
Ovim su pokriveni slučajevi 1-3, i sada sve može nezavisno da se gradi.
Pogledajte šta sam napravio, pa javite da li je to ono na šta ste mislili.
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/0809ea69/attachment-0001.htm>
More information about the QGHG-it-dev-list
mailing list