[QGHG-it-dev-list] CMake
Marko Vojinovic
vmarko at ipb.ac.rs
Wed Nov 30 23:20:55 CET 2022
Ok, snasao sam se --- treba da napravim direktorijum "build", da udjem u njega, da konfigurisem cmake sa
cmake ..
i onda da kompajliram sa
cmake --build .
Saljem ovo na listu cisto da se zna, ako nekome zafali kasnije... ;-)
:-)
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, Marko Vojinovic wrote:
>
> E da, to lici da je to, mislim da je sad to onako kako bih zeleo da bude.
>
> Jedino jos uvek ne razumem skroz kako cela ta stvar zapravo radi, ali
> naucicu. Nego, kako se zapravo pokrece kompajliranje? Recimo da sam git
> pull-ovao ceo tvoj branch, i otvorio sam prompt u osnovnom direktorijumu.
> Jel' treba da mu kazem "cmake --build", ili nesto drugo?
>
> :-)
> 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,
>>
>> 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
>> 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