Fórumok
Ez most nem költői kérdés, a mysql fordításához kellene, amihez először őt magát is szeretném lefordítani (persze nem megy, naná). Továbbá szeretném tudni, hogy mi is ez? Mármint nem a marketing szöveget, hanem az effektív információt; úgy értem a leírásokat, hogy ez a 'configure' kiváltója akar lenni, de úgy tűnik (legalábbis abból, hogy a saját fordításhoz önmagát is haszálja), hogy a make feladatát is átveszi, illetve abba is belekavar.
Hozzászólások
Egy Makefile generátor, a célja ugyanaz, mint az autoconf-automake párosnak, csak egy kicsit újabb, meg szerintem sokkal jobb. CMakeLists.txt fileban van a buildhez szükséges info, ebből gyártódnak a végső Makefileok.
Alap használat pl.:
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/opt/project ~/source/tree
make
make install
ccmake pedig egy egyszerű kis UI hozzá, ahol a CMake változók állapotait meg tudod nézni.
Köszi!
Eddig az volt a legtöbb, amit elértem a CMake fordításával, hogy összelinkelkelte saját temporális énjét az én LDFLAGS beállításaimmal, de azután a végleges verziót már a saját módján akarta csinálni (mert természetesen ő jobban tudja, hogy hogyan kell AIX-on linkelni, mi én), és persze az előállt program nem futtatható (a -Wl,-blibpath -t volt szíves elrontani, nem volt benne a /usr/local/lib)
Saját magát még sosem fordítottam vele :)
Annyival egészíteném ki, hogy tudtommal az egyetlen meta-project leíró tool, ami támogatja a cross platform és multi target fordítást.
Az ötlet az, hogy leírod a projectedet CMake-ben, és innentől ő legenerálja a megfelelő projectfileokat minden platformra. Legyen az GNU Make alapú gcc, Visual Studio gmake, Visual Studio Solution, vagy amit akarsz, körülbelül minden fordítót és compiler-t ismer. Amit nem, azt Te beleintegrálhatod.
És undorító szintaxist használ.
Ha amúgy valaki CMake expertnek érzi magát, szóljon, mert keresünk kollegát ilyen profillal. Jó fizetés, Írország, fürdőskurvák, eső.
"És undorító szintaxist használ."
De legalább csak egyet, ellentétben az autotools-szal.
Másik nagy előnyének szokták mondani, hogy az autotools nagy része alatt csomó interpretálás után egy bash script fut, ami posix rendszereken se gyors, de windowson borzalmas lassú, a cmake meg egy bináris. Meg állítólag figyelnek a visszafele kompatibilitásra, ellentétben az autotools-szal.
Sajnos nem nagyon ismerem amúgy, de az autotools miatt szívtam elég sokat, annál szerintem bármi jobb.
Annó használtam cmake-t, nekem annyi maradt meg belőle hogy korábban fél órát kellett várnom a forgatásra ha módosítottam 1 fájlt, cmake-el pedig csak azt az 1 fájlt forgatta le újra ami módosult, így kb fél perc volt az újraforgatás. Persze ez debianon volt, de gyanítom itt is ugyanazt fogja tudni (de fixme ha nem).
Mondjuk ezt a sima make is tudja, ha rendesen be van lőve. (ugyebár ha headert módosítasz, az sokmindent magával ránthat persze)
Off: itt van egy hasznos doksi make ügyben: http://aegis.sourceforge.net/auug97.pdf
On: egy újabb nekifutásnál kevesebbre jutottam, mint az előbb, ennél a lépésnél fagy jéggé:
Eddig jutottunk a debuggal:
így kellene tesztelni:
1. meglátás: abszolút PATH-névvel futtassuk, ne relatívval:
Most már elárulhatom, a sok zavaró tényező egyike az volt, hogy a -GUnix Makefiles az igazából -G'Unix Makefiles', vagyis a vidám fiúk szóközt taralmazó fájlnevet bírtak létrehozni. Ezek után azon se csodálkoznék, ha megtudnám, hogy házioltárt emeltek BG tiszteletére, és az előtt szoktak kakast áldozni.
jol elhuzodott a debugging :-)
-------------------------
Roses are red
Violets are blue
Unexpected '}' on line 32
De legalább meglett a hiba! És a kitartás egy új dimenziójával ismerkedhedtünk meg.... :)
+1, néha azon gondolkodom, hogy most vagy ő a nem normális vagy én. :D :D
A jegyzőkönyv kedvéért: lámafalva kis lakói (értsd: a cmake 'bootstrap' scriptjének tudós összeállítói) nem hallottak még a CPPFLAGS-ról, tehát ha a large-file-support-ra vonatkozó opciók sem jutottak el a g++ -hoz. Gáz.
Igazából a CPPFLAGS a C PreProcessor flagjainek a változója. Bár ettől még nem kéne figyelmen kívül hagynia a cmake-nek.
+1
Nagy öröm, hogy legalább következetesek: ez máig is így van;)
Ha ezt javítjuk, eljut odáig, hogy van neki valamiféle beépített libcurl-je, és annak a fordításába pusztul bele...
És ez nem a korszerűtlen egzotikus AIX-on van, hanem a modern, kényelmes CentOS 7.8-on.
Na, egynapos szenvedés árán rájöttem, hogy ezt a parancsot kellene kivizsgálni, miért esik végetlen ciklusba:
(a gond az volt, hogy a logban úgy látszott, hogy -GUnix Makefile van a parancsban, tehát szétesett a parancs...
truss szerint ilyesmi a vége:
Vagyis mintha az end-of-file már egy túl bonyolult jelenség lenne, amit csak végtelen ciklussal lehet elviselhetővé tenni...
Ilyesmit ír a gdb utolsó erejével:
Namostan ez tényleg lehet egy file-másolás, de vajon mi a gond?
Mondjuk egy kicsit korábban egy érdekes komment van:
(Off: kb 25 éve mondogatom, hogy a C++ egyelőre kiforratlan, experimentális termék, komoly munkára ne használjuk, de figyel rám valaki?! Naná, hogy nem.)
De bakker az eof sok mindennek nevezhető, de hibának nem. Az más kérdés, hogy ha tovább erőltetem azt a rohadt read-et, onnantól már persze hibát kap, persze hogy mi lesz a gcount-ban, arról halvány dunsztom nincs. Mondjuk naívan azt mondanám, hogy akkor is 0, de azt azért nem látom, hogy attól, hogy túlolvastam a fájl végén, a fin mitől válna 0-vá - lévén én fenti részletben nem a fin-gcount, hanem a fin alapú ciklust látok. Szóval vagy én vagyok totál hülye (ez azért nem kizárt), vagy programozó úr rontott el valamit - vagy csak simán félreértem azt a kódrészletet.
Szerk: a 4. lehetőség a megoldás: tényleg 0-vá válik a fin, ha elérte az eof-ot. azannya cxx.
No, nézem tovább, hátha a debugkiíratások elárulnak valamit...
Ez most keményebbnek látszik, mint az eddigiek, például azért, mert nem mindig ugyanaz a hibajelenség, ennél a végtelen ciklusnál jutott már messzebb is...
Úgy látom, olyan van itt, hogy 'make clean', de olyan nincs 'make distclean', és úgy tűnik, egyes generált komponensek túlélik a 'make clean'-t.
Most éppen itt tartunk:
cmCacheManager.cxx:LoadCache függvény olvassa a 'CMakeCache.txt' fájlt, aminek ilyen a vége:
és ebből ilyesmi fakad:
Na itt egy tesztprogram, ami nekem nagyon másképp megy linuxon, mint AIX-ben...
http://web.axelero.hu/lzsiga/ifstreamtest.cc
mondhatni AIX-on a második olvasási módszer végtelen ciklust generál, az elsőnél meg az 'iostate' állítása problémás nekem...
Ilyenek vannak nekem telepítve:
A jelenség egyforma 32/64 biten, AIX-oslevel=6.1.0.0
while (is) {
getline (is,line);
cout << line << '\n';
}
http://www.cplusplus.com/reference/ios/ios/operator_bool/
Returns whether an error flag is set (either failbit or badbit).
Notice that this function does not return the same as member good, but the opposite of member fail.
Azaz eof esetén, ha olvasási hiba amúgy tulajdonképpen nincs, ez a while elvileg örökké fut. Ennek fényében nekem az meglepő, hogy linuxon nem kapsz végtelen ciklust, de gondolom van rá valami logikus magyarázat.
EOF esetén is kilép (egyébként nem éppen elegáns módszer, bár TurboPascal-ban tényleg így szoktuk: előrször EOF-ellenőrzés, aztán olvasás -- mert ott az EOF-ellenőrzés tartalmazta a bufferbe olvasást)
Magam sem értem egészen, amit most mondani akarok, de azért a jegyzőkönyv kedvéért:
a fordító szerint az 'ifstream' és az 'ios_base' között 280 byte a különbség, a debugger és libstdc++ szerint 224...
Najó, kicsit pontosabban:
ebből a RTTI-t nem értem, de a címek közötti különbség zavar...
Szerk... Szóval a _M_filebuf mérete az egyik komponens szerint 208, a másik szerint 264.
Szerk^2: típusa a ' __filebuf_type', és a 'fstream' nevű hedaer teszi bele a a különböző osztályokba; mégpedig így typedef-eli:
Szerk^3: hajlok arra, hogy _M_lock-ot is a hiba részesének tekintsem: az egyik komponens szerint 64 byte a mérete, a másik szerint csak 4
Na jó, az előző hozzászólás már teljesen elkopott a sok szerkesztgetéstől, akkor most itt tartunk:
Szerk: az a __c_lock pedig, tisztelettel mondva, ilyen:
Viszont a __gthread_mutex_t nem más, mint a 'pthread_mutex_t' és az 'int' valamelyike, fordítási opcióktól függően.
Annyi biztos, hogy a pthread_mutex_t ilyen:
Szóval, a gond alapvetően ott van, hogy két libstdc++ van, ami a következő négy:
32-bit, pthread-nélkül (__gthread_mutex_t=int)
32-bit, pthread-dal (__gthread_mutex_t=pthread_mutex_t)
64-bit, pthread-nélkül (__gthread_mutex_t=int)
64-bit, pthread-dal (__gthread_mutex_t=pthread_mutex_t)
Namostan olyat én nem tudok csinálni, hogy egy kis ilyen, meg egy kis olyan, azután majd jól összelinkelünk valamit; tehát azt választom, hogy a pthread-ost nevezem ki alapértelmezettnek. (Ezt azzal fejezem ki, hogy a /usr/local/lib -be telepítem.)
(Márcsak azért is, mert én tulajdonképpen a tesztprogramban sem mondtam, hogy -pthread, legfeljebb annyit, hogy -D_THREAD_SAFE (szerk: és ez pont elég is a "gthr-default.h"-nak))
Akkor most 'egész jók' vagyunk, a 'teljesen jóhoz' az kellene, hogy a linkelésnél az én kis rögeszmém érvényesüljön, ne az övé.
Az övé ilyen (dump -H):
Az enyémben ilyesmi lenne (egy másik programból idézve):
(pathnevek, verziószámok, katonás fegyelem;)
parancsolj:
Csak úgy kíváncsacsiságból megkérdezném: elképzelhető, hogy a cmake és a libtool kizáró kapcsolatban vannak?