CMake - je to výhra? (diskuse)

[deda.jabko]

zkus SCons!

nedavno jsem taky hledal nahradu za autotools a cmake mne prisel uplne stejne dementni... sice v scons neni javascript, ale python (prast jak uhod)... kazdopadne, vsechno lepsi nez autotoolovska zmet m4 a bashe ;-]

[slayn]

souhlas!

[rastos]

Ako cmake tak scons ma privádzajú do vytrženia, keď potrebujem do väčšieho cudzieho projektu doplniť cestu ku knižniciam. Dopátrať sa odkiaľ sa tie hodnoty berú je o držku. Možno to nie je chyba tých nástrojov, ale toho ako sú použité ... ale aj tak. Upraviť obyčajný Makefile alebo configure skript nikdy nie je také trápenie ako upraviť cmake/scons súbory.

[Michal Čihař]

Cesta se většinou zadává nějakým parametrem, takže si pusť ccmake nebo cmake-gui a nastav si to tam.

[Michal Čihař]

SCons je celkem pěkný, ale nechápu proč tam neexistuje (nebo aspoň mi to tak připadalo) nějaká sada základních testů. Proč by s sebou každý program měl nést třeba kód na detekci verze knihoven pomocí pkg-configu?

[Jardík]

Jenže SCons vyžaduje python. Kdyby to dokázal interpretovat sám o sobě, tak bych to bral, ale instalovat např. na Windows python jenom proto, abych si zkompiloval jediný projekt je zbytečnost a použití SCons k tomu přímo donucuje (já vím, existuje 64bit python pro Windows, akorát s tím máloco počítá, takže si pro Windows stáhnete nějakou (externí) pythoní knihovnu, ona používá céčkovou knihovnu, ale tu vám dají jen 32bit a je tu problém). CMake je alespoň spustitelná binárka sama o sobě a nepotřebuje další věci. To je pro mě hlavní výhoda cmake. A autotools na Windows je ještě větší humus. Vyžaduje to cygwin (jenom 32bit) nebo msys (taky 32bit) a nepočítá to s 64bit mingw (mingw-w64), takže s tím je to taky nepoužitelné. CMake se ke spolupráci s mingw-w64 alespoň dá donutit. Ale o tom linuxáci nepřemýšlej, protože ti mají bash i python v každé distribuci ve výchozím stavu nainstalovaný a je jim ukradené, že některý systém (obzvláště ten od MS) to tak nemá.

[kozzi]

+1

[Michal Vyskočil]

Ale o tom linuxáci nepřemýšlej, protože ti mají bash i python v každé distribuci ve výchozím stavu nainstalovaný a je jim ukradené, že některý systém (obzvláště ten od MS) to tak nemá.

Proč by Linuxáci měli vůbec řešit nějaké problémy Windows?

[kozzi]

No tak linuxáci by to opravdu řešit neměli. Ale lidé co dělají aplikace pro oba systémy, ti by to měli řešit

[zde]

> Ale o tom linuxáci nepřemýšlej, protože ti mají bash i python v každé distribuci ve výchozím stavu nainstalovaný cygwin i msys mají bash i python taky ve výchozím stavu nainstalovaný.

[Jardík]

Ano, ale 32bit bash, 32bit cygwin, kýbl dalších knihoven, pochybná funkčnost pod Windows Vista, kde se ani pořádně nedokončí instalace (maj to špatně udělaný, není to chyba Windows). To už radši nainstaluju nativní (64bit) python, než instalovat cygwin/msys.

[Marián Kyral]

Abych řekl pravdu, cmake beru jako magii. Absolutně se v něm nevyznám. Když něco potřebuji, tak si musím najít, jak se to dělá jinde a pak to s mírnými úpravami použít.

 

[default]

No, já přímo v C/C++ naštěstí dělat nemusím, takže mě to nemusí vůbec trápit. Ale! Instaloval jsem nějakej program přes MacPorty a ten hajzl vývojář používá cmake. Takže kvůli jedný blbině jsem musel stáhnout a zkompilovat cmake a jeho závislosti.

A jak tak čtu tu ukázku, jsem nesmírně vděčný za Apache Ant.

[Kvakor]

Ano, ta syntaxe podmínek je vpravě obludná.

[msk]

WTF? Ant? Popis kompilacie pomocou xml? To uz musel vymysliet kokot...

[Ladicek]

Sice se o pár řádek níž vyjadřuju vůči Antu značně zdrženlivě, ale jedno mu nelze upřít: tisíckrát lepší peklo s XML než peklo s tabulátory!

[Josef Kufner]

Tobě editor nezvýrazňuje nevhodně umístěné mezery?

[Ladicek]

Dneska jo, ale to už naštěstí žádné Makefile psát nemusím Myšlenku významových bílých znaků jsem za svou rozhodně nepřijal, a tabulátory obecně ve zdrojácích nesnáším.

[mirec]

offtopic: Prečo "programátori" tak neznášajú tabulátory? Nevidím u nich žiadnú nevýhodu, môžem si sám určiť koľko medzier sa mi zobrazuje, zaberá to menej priestoru na disku, nerozbije sa to (snáď až na pár editorov ako notepad, ktoré rozbijú akýkoľvek text) ak človek dodržiava isté veľmi jednoduché pravidlá. No a samozrejme editor mám nastavený tak aby tabulátory a prebytočné medzery zobrazoval.

[default]

Já je nepoužívám právě proto, že vyžadují nastavení editoru. Zkus pročítat nějaký složitější kód na klasickém terminálu 80 na 24. Ano, můžeš namítnout, že si mám zvětšit xterm, ale bohužel já UNIX mám, ale ostatní mají PuTTY. A jen proto, že potřebuji rychle něco najít nebo opravit, nebudu jim přenastavovat úplně všechno (včetně připadných dalších programů). Takhle mám zdrojáče připravené pro všechna prostředí. Tak proto.

[mirec]

Příloha:

• 80x24.png (62211 bytů)

No 80x24 je des, ale používanie tabov môže byť práve na takýchto hrúzach lepšie. Ak si nastavím šírku tabu povedzme 2 znaky zmestí sa mi na terminál viac, ako keď mi niekto vnucuje odsadenie 4 medzerami.

Len pre zaujímavosť rovnako ako xterm sa dá zväčšiť okno PuTTY.

Nastavenie zobrazovania whitespace je väčšinou veľmi triviálna (napr. vo vim-e je to 1 krátky príkaz).

V prílohe je môj terminál s úbohým rozlíšením 80x24, na screenshote vidno taby a prebytočné medzery (1 príkaz na nastavenie oboch súčasne ;) ).

[spang]

Co je to splitnuté vlevo za plugin? To vypadá užitečně, zvlášť jestli se to dá snadno schovávat.

[mirec]

Je to project plugin, zobrazuje sa klávesou F12 (ja mám ale namapované na F8, F12 radšej používam na prepínanie medzi hlavičkou a implementáciou). Medzerník zväčší panel na takmer maximum (samozrejme po ďalšom stlačení sa zmenší na pôvodnú veľkosť). Pozor tento plugin nie je žiadna výhra .. pre plugin, ktorý zobrazuje tagy (niečo ako taglist) spoločne so zoznamom súborov v projekte odporúčam pozrieť VIDE.

[Marián Kyral]

 

No 80x24 je des, ale používanie tabov môže byť práve na takýchto hrúzach lepšie. Ak si nastavím šírku tabu povedzme 2 znaky zmestí sa mi na terminál viac, ako keď mi niekto vnucuje odsadenie 4 medzerami.

Mně osobně taby ani mezery až tak nevadí, přizpůsobím se když je potřeba, ale co mi vadí je vzájemné míchání. Když to jeden dělá tak, druhý jinak, tak mám část kódu odsazenou na dva tabulátory, část na čtyři mezery a něco třeba na osm mezer. Bohužel u velkých projektů se to málokdy podaří uhlídat. Vývoj trvá několik let, pak se několik let opravují chyby, dodělávají nové funkce, pracují na tom mraky programátorů s různými zkušenostmi, většinou ani nedostanou dokumentaci a na nějaký styl kódu se moc nehraje. Hlavně, že to funguje

 

Když se ke mně dostane taková hrůza, tak to většinou musím přeformátovat, jinak se v tom nevyznám.

[default]

Patrně jsi opomněl, že se nejedná o mé prostředí, ale o prostředí druhých. Kvůli tomu, že já jsem na něco zvyklý, nebudu jim všechno přenastavovat, že?

[Ladicek]

To nemá nic společného s programátory v uvozovkách či bez nich. Já zase nevidím u tabulátorů žádnou výhodu, naopak mezery poskytují konsistentní formátování za každých okolností. Sám si můžu určit… – bullshit, chci vidět vždycky všude všechno úplně stejně. Hlavně v té strašlivosti, která začíná písmeny vé a í

[mirec]

naopak mezery poskytují konsistentní formátování za každých okolností

Keď človek nie je úplný magor tak je formátovanie tabmi konzistentné za každých okolností (bez ohľadu na editor, aj v notepade .. teda keby som používal konce riadkov ako MS). Na odsadenie medzerami si musím nastaviť editor tak aby bol prispôsobený na počet medzier ktoré sú v zdrojovom kóde použité ako odsadenie aby som po stlačení backspace mohol zmenšiť odsadenie o správny počet medzier. Pri použití tabov backspace za každých okolností v každom editore zmenší odsadenie. Jediné čo vidím nekonzistentné je rôzna šírka tabulátora [čo je aj tak väčšinou 4 znaky, nehovoriac o tom, že takmer vždy (aj v krčme) mám so sebou vlastný notebook na ktorom robím radšej].

[default]

Nemyslím si. Má to i své výhody. Například takové dynamické generování build scriptů za běhu buildu. Takhle mám XSLT transformačku, která z lidského XML vygeneruje Antí hnus. Kdybych toto měl dělat pro nějaký programovací build engine, musel bych řešit gramatiky, parsery, generátory a já nevím co všechno.

Uznávám, že je to silně nezvyklé, že to na provní pohled může působit jako WTF, ale jsou případy, kdy to prostě na plný čáře vyhrává… Já bych to být tebou tak kategoricky neodsuzoval.

[Ladicek]

Kdybych toto měl dělat pro nějaký programovací build engine, musel bych řešit gramatiky, parsery, generátory a já nevím co všechno.

Nikoliv, stačí použít API

[default]

Jasněé. A proč to rovnou nenapsat v byte kódu. A nejlépe rovnou zazipovaný v jaru.

[Ladicek]

To je mimo. U Antu je dynamické generování build.xml samozřejmě jediná možnost, ale u programového systému nemusím nejdřív generovat skript, který pak nechám provést, stačí rovnou volat to, co potřebuju. V Javě lze použít třeba PJMake.

[spang]

Heheh, to bych teprv chtěl slyšet co bys řekl na standardní XML dokumentační komentáře v C#, tam se valí XML rovnou do kódu .

[Deleted [8409]]

Pro parser to je ale pohoda, ne Mi osobně ty komentáře nevadí, akorát to zabere moc místa :)

[Ladicek]

Jo! To jsem vůbec nepochopil a když jsem to viděl prvně, zíral jsem jako Jardík na ženskou. Javovské taglety jsou asi tak miliónkrát lepší.

[zdenek-hbr]

me se libi ze muzu pomoci CPack jednoduse vytvaret debiani balicky

[l4m4]

Po cmake jsem se poohlížel. když jsem si říkal, zda nenazrál čas nahradit autotools něčím modernějším, ale právě čtení .cmake souborů KDE mě dost odradilo, protože oproti tomu je i čtení vygenerovaného configure pohoda.

A scons... python se čte i píše báječně, ale scons (zatím) neintegruje zdaleka vše, co bych chtěl. A popravdě řečeno, asi nebudu spokojen, pokud build systém nebude mít integrovaný libtool, jelikož tomu už jakžtakž věřím, že dokáže udělat verzované sdílené knihovny, dynamické moduly a pod., jak si představuji.

[kavol]

hm, čistě z uživatelského hlediska ... kdysi dávno pradávno, když se cmake začínalo prosazovat, bylo prezentováno jako úžasná výhoda, že "configure" fáze netrvá věčnost jako u autotools, u Gentoo dokonce s tímto argumentem zrušili monolitické KDE ebuildy ... no tak nevím, ale když tak pozoruju kompilaci KDE 4, a u leckterého balíčku trvá "configure" dýl než samotná kompilace, tak si říkám, kde udělali soudruzi chybu ...

[Marián Kyral]

Které například?

Jako výhodu cmake vidím hlavně v tom, že tam není obludný skript configure, který měl i u jednoduchého projektu klidně 1MB.

[kavol]

Které například?

třeba kglobalaccel se mi tak jeví ... a podotýkám, že to mluvím o prvním pokusu a ne o následných rekompilacích se zapojením ccache (protože se mi ta blbost aktuálně nenainstaluje :-/, tak běhů s ccache jsem viděl dost, a tam je to rychlejší znatelně)

[Marián Kyral]

Máš jen 4.2.67, nebo máš i paralelně 4.2.1?

[kavol]

Máš jen 4.2.67, nebo máš i paralelně 4.2.1?

ted mam XFCE z instalacniho CD, neb testovaci stroj mi zhebnul

(jesteze jako kazdy spravny pocitacnik mam doma kupu srotu, ze ktereho se da poskladat funkcni masina ...)

nicmene bylo to ciste 4.2.67 ... resp. tak ciste, jak ciste to dokaze udelat emerge -avuDN world; emerge @preserved-rebuild; emerge --depclean ...

[Marián Kyral]

Aha. Já mám totiž 4.2.1 a potřeboval jsem vyzkoušet aktuální verzi gwenview. Tak jsem odmaskoval gwenview, kdelibs a ještě pár balíku a nahodil gwenview z 4.2.67. To sice šlapalo, ale instalace kipi-pluginu selhala, protože závislosti byly v 4.2.1. Takže mi z toho vychází buď 4.2.1 nebo 4.2.67, dohromady to asi nebude jen tak

[Marián Kyral]

BTW: a myslíš si, že s autotools by to bylo rychlejší, nebo snad srovnatelně rychlé?

[kavol]

BTW: a myslíš si, že s autotools by to bylo rychlejší, nebo snad srovnatelně rychlé?

nemyslím ... a btw, ty myslíš, že cmake bude za těch N let, až to bude stejně staré, jako nyní autotools, stejně rychlé jako současná verze?

[Marián Kyral]

Nejsem věštec, ale klidně by cmake mohlo být ještě rychlejší.

[Deleted [8409]]

Mám gentoo, a musím uznat, že cmake je rychlejší než autotools. Configure skript mi běží někdy i půl minuty, cmake ani nepoznám. Jde asi i o to, že ty configure skripty řeší i to, co aplikace nepotřebujou (třeba v každém vidím něco o detekci fortranu).

Jinak čistě z uživatelského hlediska je podle mě zase lepší používat cmake. Když se podívám, kolik těch autotools verzí musím mít nainstalovaných, tak je mi z toho zle:) Ale jak jsem psal v blogu, moje spokojenost s cmake je na hranici.

[kavol]

Configure skript mi běží někdy i půl minuty, cmake ani nepoznám.

njn, a mě zase cmake někdy běží klidně i půl minuty ... kromě toho, "configure" často proběhne relativně rychle, ale vytváření .moc je na dlouhý lokte, což jsem u projektů zkompilovatelných i s qmake při kompilaci s qmake nepozoroval ...

Jinak čistě z uživatelského hlediska je podle mě zase lepší používat cmake. Když se podívám, kolik těch autotools verzí musím mít nainstalovaných, tak je mi z toho zle:)

hm, jako kdyby cmake občas taky nevyžadovalo přesnou verzi ...

[Scarabeus IV]

CMAKE vyzaduje >=; zatimco AUTOTOOLS vetsinou potrebujou =.
Ale to je pravda jen u hodne z***venejch build systemu.

[Ondrej 'SanTiago' Zajicek]

> Když se podívám, kolik těch autotools verzí musím mít nainstalovaných

A proc jich mas tolik nainstalovanych?

Pro normalni kompilaci ze zdrojaku (vyuzivajici autotools) by nemely byt autotools potreba. Ty jsou treba akorat tak pri kompilaci software z vyvojarskeho CVS (ci jinych nereleasovanych zdrojaku) nebo v pripade, kdy autor neumi udelat zdrojakovy balicek. Nebo kdyz jsi sam vyvojar, pak ti ale nic nebratni ve svych projektech prejit na jednu verzi.

[Deleted [8409]]

Já nepoužívám autotools, ale gentoo jo:) Některé balíky asi vyžadujou verzi autotools v nějakém rozmezí. Musím ale uzat, že dřív to bylo horší (klidně i 6 verzí).

[Deleted [8409]]

Navíc jak už bylo zmíněno, pro multiplatformní vývoj je fakt lepší cmake. Sice ta syntax je šílená, ale dá se v tom vytvořit projekt, který bez problémů zkompiluju pod Win/Lin.

[David Watzke]

No, lepší než patchovat configure je opravit to níž a vygenerovat ho znova... a tak to na Gentoo chodí.

[Scarabeus IV]

To dela vetsina balickaru. To neni specialitka gentoo :]

[David Watzke]

To je mi jasný, ale když to udělá řekněme šéfík z Debianu, tak to uživatelům může bejt fuk a on to jen pošle upstreamu nebo tak...

[Scarabeus IV]

Vzhledem k tomu ze i my ty patche posilame upstreamu tak v tom fakt nevidim rozdil.

[David Watzke]

Já vím, ale původní téma je pokud vím proč někdo potřebuje X verzí autotools. Tak jsem se to pokusil objasnit, to je vše.

[kozzi]

Zrovna včera, když jsem seděl na záchodě jsem nad problematikou autotools,qmake, SCons a CMake přemýšlel. A mé závěry byly velmi podobné jak tvé, co se CMake týče. Autotools fakt nee, qmake ten toho zas umí málo, je fajn jen pro malé qt aplikace. SCons má python syntaxi což mi vcelku vyhovuje, ale jak už Jarda psal má to tu nevýhodu, že musí být nainstalován python. No a CMake si popsal dokonale, ta syntaxe je občas fakt děs.

[Rezza]

Jj, syntaxe je des... V KDE je aspon pekne, ze je napsanych milion ruznych cmake modulu, funkci atd., takze i slozitejsi veci se daji delat jednoduse... Horsi pokud si clovek chce napsat vlastni ne KDE ci dostane do rukou jiny projekt, ktery to ma zmrsene... I kdyz i rucni prekladani by bylo lepsi nez Autotools! Naposledy jsem bojoval s Gnashem...

[Josef Kufner]

Tak co napsat podporu alternativni syntaxe pro cmake? Veškeré funkce ponechat jak jsou, jen tomu dát hezčejší závorky, značky, symboly,... Na začátku souboru by pak mohl být příkaz pro přepnutí syntaxe a hotovo. Pokud sémantika bude stejná, nemělo by to být nijak obtížné.

[Kvakor]

Možná by stačilo řešení jako u Sendmailu - neměnit cmake, ale jenom přidat skript, který by ty "hezčejší závorky, značky, symboly, ..." podporoval a vygeneroval z nich vystup pro cmake.

[Ladicek]

Preprocesor pro cmake, který je preprocesorem pro make?

[frEon]

odborne se tomu rika rovnak na ohejbak

[Deleted [8409]]

Když se podívám na tu syntax cmake, tak si myslím, že by něco takového nebylo možné.

[Josef Kufner]

To mě napadlo taky, ale byl by v tom příliš veliký bordel. Zdvojení parseru vyjde daleko lépe.

[Rezza]

A budeme mit dalsi moloch ala autotools... Proste je trebas si zvyknout a basta...

[spang]

S většinou připomínek souhlasím, ale nějak zvlášť mě nepálí i když CMake používám. Syntax mi nevadí, číst se to dá, upravovat taky a většinou toho zas tak moc není. Z hlavy ty funkce není potřeba znát, stejně je napíšu jednou a příště až u dalšího projektu, mezitím bych zapomenul cokoli. Co mě mrzí mnohem víc je nic moc dokumentace. Nikdy z ní nedokážu vyčíst co potřebuju nebo jak se co používá, ať už šlo o trivialitu jako zapnutí -Wall pro gcc, nebo něco složitějšího, jako linkování programu s Qt a prohnání souborů 'moc'em. Ale když jsem to někde našel v příkladu, tak to tak hrozné není. Používá se to fajn, když už si to člověk jednou hezky nastaví.

Na debug definice používám tohle:

OPTION(project_DEBUG "Build the project with debugging code" OFF)
IF(project_DEBUG)
  SET(CMAKE_BUILD_TYPE Debug)
  SET_SOURCE_FILES_PROPERTIES(${project_SOURCES} COMPILE_FLAGS -DDEBUG)
ELSE(project_DEBUG)
  SET(CMAKE_BUILD_TYPE Release)
ENDIF(project_DEBUG)

Defaultně je pak debug vypnutý ("OFF" v prvním řádku), vývojář si ho může natrvalo zapnout pomocí 'make edit_cache' a přepnutím příslušného flagu.

[mirec]

Tak tak, tiež mi k CMake chýba poriadna dokumentácia. Minule keď som musel robiť v jave som musel siahnuť po obyčajných makefile súboroch (keďže podpora javy v CMake vôbec nie je zdokumentovaná).

CMake mimochodom podporuje niečo ako CMAKE_CXX_FLAGS_RELEASE, CMAKE_CXX_FLAGS_DEBUG, dá sa to využiť napr.

set(CMAKE_CXX_FLAGS_RELEASE "-O2 -Wall -DNDEBUG")
set(CMAKE_CXX_FLAGS_DEBUG   "-O2 -ggdb -Wall -DDEBUG")

if(CMAKE_BUILD_TYPE MATCHES Debug)
	message(STATUS "Configured to compile including full debug information in the executables")
else(CMAKE_BUILD_TYPE MATCHES Debug)
	message(STATUS "Configured to compile including debug information in the executables")
	set(CMAKE_BUILD_TYPE Release)
endif(CMAKE_BUILD_TYPE MATCHES Debug)

[default]

Minule keď som musel robiť v jave som musel siahnuť po obyčajných makefile súboroch

Pro příště: Apache Ant. Vzhledem k tomu, že v Javě neděláš, tak zkus příště NetBeans. Ty za tebe ten build.xml vygenerují. A ten se dá dost dobře ohnout. Možná bych o tom mohl něco víc napsat…

[mirec]

Pravdu povediac nemám chuť písať xml kvôli programom typu "hello world" rovnako ako sa mi nechce čakať 10x dlhšie na štart IDE než na štart kompletného systému a štart odľahčeného "IDE". Ak by som písal aj niečo iné ako pár riadkové príklady do školy vtedy by sa mi už IDE mohlo hodiť ... alebo by som možno použil SCons a napísal 1 riadok kódu (nie nemám fóbiu z xml ;) ).

[default]

No, tak to naprosto chápu. Pro pár řádek bych se s Antem taky moc ne… to, no — neobtěžoval.

[Michal Vyskočil]

Pravdu povediac nemám chuť písať xml kvôli programom typu "hello world" rovnako ako sa mi nechce čakať 10x dlhšie na štart IDE než na štart kompletného systému a štart odľahčeného "IDE".

Jenže zatímco make spouští pro každý soubor javac, ant defaultně kompiluje všechno v jednom. A podle mých zkušeností je i pro poměrně malé programy overhead opakovaného spouštění javac nesnesitelně velký. No a na vytvoření jednoduchého build.xml není potřeba spuštět těžkotonážní IDE

[Ladicek]

Nikdy více Ant! Když už, tak Gant, lépe Gradle

[default]

Můžeš to prosím trošku rozvést?

[Ladicek]

Ono opravdu psát skript v XML je zoufalství. Já vím, žádné ify a tak… Ale to je prostě peklo. Build je proces, a proces se popisuje programem – v případě Gantu a Gradle programem v Groovy. Perfektní využití skriptovacího jazyka.

[default]

Build je proces, a proces se popisuje programem

Tento argument s dovolením neberu. Proces se popisuje diagramem (například v UML). Jen určité typy procesů se dají implementovat programem. A zrovna ten proces sestavení programu nemusí být implementován programem. Na ten Gant a Gradle jsem se díval a moc mě to nepřesvědčilo. Ale asi jsem jen moc zvyklý na Ant… Ale uznávám, že je to spíš akademická diskuze.

[Ladicek]

Diagramy jsou pro managory, analytiky, architekty a podobnou svoloč

[default]

Tak tenhle argument beru.

[Scarabeus IV]

Tak podminky se nemusi ukoncovat s nazvem sveho obsahu:

IF ( ENABLE_AUTOTOOLS )
    BLABLALBA
ELSE ( ENABLE_AUTOTOOLS )
    BLBABLABLA
ENDIF ( ENABLE_AUTOTOOLS )

lze take zapsat jako:

IF ( ENABLE_AUTOTOOLS )
    BLABLALBA
ELSE ()
    BLBABLABLA
ENDIF ()

je jen na uzivateli zda to zapne. Treba me se ta nutnost libi pac si nemusim psat komentare co je to za blok kodu.

Debug vysvetlil uzivatel spang tam se zdrzovat nebudem :]

FindThreads je ocividne blbe napsanej pac by mel vracet ktere promenne jsou povolene a s cim se da linkovat, tedy by melo stcit napsat jen to co je vnorene v te podmince. Da se rict ze cmake a autootols lze psat jak prasacky tak citenle. Problem je ze vetsina lidi to pise prasacky. Jen proboha nepouzivejte zadny prisernosti typu scons nebo bam. Lidi si to vetsinou neuvedomujou ale programovat primo python pro napsani build pravidel je dost silenost a to same plati u bamu kde pro zmenu treba generuje C soubory primo z podivnejch pseudosilenosti (neco mezi textakem a ceckovim zdrojakem) do .h nebo i .c.

[Deleted [8409]]

To o těch podmínkách jsem nevěděl. Začínal jsem s verzí 2.2 nebo 2.4 a tam to asi nebylo:)

Ale jen bych doplnil to, že cmake podle mě používá syntax, která k té prasečině svádí. Má velmi stručnou dokumentaci, a když chce člověk napsat něco vlastního, tak je rád že to nějak funguje. Přiznám se, já v tom asi prasím taky (a to se snažím aby to tak nebylo).

Jinak ty další systémy mě moc nezajímají, na cmake se mi líbí právě to, že to je jen jeden balíček, který je k dispozici i pro Windows v binární podobě (takže rozchodit něco pod windows je otázka stažení a nainstalování cmake). Třeba scons se mi podařilo pod Windows nainstalovat až napodruhé.

[Scarabeus IV]

To souhlas, dostat neco z cmake dokumentace je porod. Vetsinu tech veci sem se naucil obskurnim prohrabavanim google :] A zurivym testovanim na tuxancich :D

Ja do dneska nechapu proc neni gui nastroj kde clovek nasype zdrojove soubory jake chce exace z ceho a kam soupat jaka data.

[Rezza]

Ja zase skrze cele KDE - nektere veci jsou prasacke, nektere pekne, jako kazdy kod...

[Deleted [8409]]

Když to tak vidím, tak mám pocit, že cmake není žádná spása, ale jen nejmenší zlo :) Jsem rád, že to hodně lidí vidí podobně.

Kdybych měl víc času a nic na práci, tak bych se do toho projektu asi pustil. Jako javascriptový engine by se dal použít KJS nebo SpiderMonkey. Musely by se napsat funkce pro umožnění skriptu dotknout se filesystému a spouštět další procesy (a čekat až to skončí) - Toto už je pro spidermonkey myslím i napsané. Největší problém by podle mě nebylo napsat ten tool, ale napasovat tam všechny ty platformní blbosti, které cmake už obsahuje a jejich vyladění by stálo určitě hodně času.

Každopádně jako bakaláčka nebo diplomka by to bylo podle mě zajímavé téma, já bych s tím rád v rámci možností pomohl. Podle ankety si myslím, že by tento projekt měl smysl.

[Grunt]

Když to tak čtu, existuje vůbec někdo kdo má rád autotools?

[Käyttäjä 11133]

Já

[wrerw]

Ja taky.

[l4m4]

Já. Ne nějak zvlášť, ale jsem na ně zvyklý a zatím to nevypadá, že by někdo vymyslel něco lepšího. Zatím lidi vymysleli pouze věci, které jsou rozbité jiným způsobem než autotools...

[mirec]

Ešte taká drobnosť ktorá mi dosť vadí na CMake - absencia PCH. PCH pri väčších projektoch môže ušetriť dosť času pri kompilácii, žiaľ CMake podporuje PCH len u ms visual studia :(

[Jardík]

Už celkem dlouho používám cmake jako hlavní generátor makefiles a projektů pro IDE. Občas, když na něco nemůžu přijít si řákám, je tento systém opravdu tak skvělý, jak nám prezentují jeho zastánci? Prostředí KDE udělalo CMake určitě pěknou reklamu, osobně jsem autotools rád neměl nikdy, takže se vývojářům KDE ani nedivím a teď musí být šťastní jako blechy. Jenže když vidím tu syntax cmake, tak si často říkám, je toto právě to co vývojáři chtějí?

Seznamovat s cmake asi nemá cenu. Programátoři v C/C++ na tento systém určitě už narazili a buď ho přijali nebo zavrhli. Já jsem byl jeden z těch, kdo tento systém přijal. Cítím se asi podobně jako vývojáři KDE - cokoliv je lepší než autotools. Jenže jak doba plyne, tak začínám tu syntax nenávidět. Připadá mi, že místo toho, aby autoři cmake použili něco smysluplného, tak museli vymyslet něco totálně jiného a celkem komplikovaného.

Následuje malý příklad mini-projektu v cmake (jedná se o cmake projekt pro knihovnu AsmJit):

cmake_minimum_required(VERSION 2.6)

Project(AsmJit C CXX)

Set(ASMJIT_DIR ".")

Set(ASMJIT_BASE_SOURCES
  ${ASMJIT_DIR}/AsmJit/AsmJitAssemblerX86X64.cpp
  ${ASMJIT_DIR}/AsmJit/AsmJitCpuInfo.cpp
  ${ASMJIT_DIR}/AsmJit/AsmJitLock.cpp
  ${ASMJIT_DIR}/AsmJit/AsmJitLogger.cpp
  ${ASMJIT_DIR}/AsmJit/AsmJitLoggerX86X64.cpp
  ${ASMJIT_DIR}/AsmJit/AsmJitLoggerX86X64Dump.cpp
  ${ASMJIT_DIR}/AsmJit/AsmJitMemoryManager.cpp
  ${ASMJIT_DIR}/AsmJit/AsmJitSerializerX86X64.cpp
  ${ASMJIT_DIR}/AsmJit/AsmJitUtil.cpp
  ${ASMJIT_DIR}/AsmJit/AsmJitVirtualMemory.cpp
)

Set(ASMJIT_BASE_HEADERS
  ${ASMJIT_DIR}/AsmJit/AsmJit.h
  ${ASMJIT_DIR}/AsmJit/AsmJitAssembler.h
  ${ASMJIT_DIR}/AsmJit/AsmJitAssemblerX86X64.h
  ${ASMJIT_DIR}/AsmJit/AsmJitBuild.h
  ${ASMJIT_DIR}/AsmJit/AsmJitConfig.h
  ${ASMJIT_DIR}/AsmJit/AsmJitCpuInfo.h
  ${ASMJIT_DIR}/AsmJit/AsmJitDefs.h
  ${ASMJIT_DIR}/AsmJit/AsmJitDefsX86X64.h
  ${ASMJIT_DIR}/AsmJit/AsmJitLock.h
  ${ASMJIT_DIR}/AsmJit/AsmJitLogger.h
  ${ASMJIT_DIR}/AsmJit/AsmJitLoggerX86X64.h
  ${ASMJIT_DIR}/AsmJit/AsmJitMemoryManager.h
  ${ASMJIT_DIR}/AsmJit/AsmJitSerializer.h
  ${ASMJIT_DIR}/AsmJit/AsmJitSerializerX86X64.h
  ${ASMJIT_DIR}/AsmJit/AsmJitUtil.h
  ${ASMJIT_DIR}/AsmJit/AsmJitVirtualMemory.h
  ${ASMJIT_DIR}/AsmJit/AsmJitWarningsPop.h
  ${ASMJIT_DIR}/AsmJit/AsmJitWarningsPush.h
)

Set(ASMJIT_COMPILER_SOURCES
  ${ASMJIT_DIR}/AsmJit/AsmJitCompilerX86X64.cpp
)

Set(ASMJIT_COMPILER_HEADERS
  ${ASMJIT_DIR}/AsmJit/AsmJitCompiler.h
  ${ASMJIT_DIR}/AsmJit/AsmJitCompilerX86X64.h
)

Include(FindThreads)
If(CMAKE_THREAD_LIBS_INIT)
  Link_Libraries(${CMAKE_THREAD_LIBS_INIT})
EndIf(CMAKE_THREAD_LIBS_INIT)

Include_Directories(${ASMJIT_DIR})

If(${CMAKE_BUILD_TYPE} STREQUAL "debug")
  Add_Definitions(-DDEBUG)
EndIF(${CMAKE_BUILD_TYPE} STREQUAL "debug")

Add_Library(AsmJit SHARED
  ${ASMJIT_BASE_SOURCES}
  ${ASMJIT_BASE_HEADERS}
  ${ASMJIT_COMPILER_SOURCES}
  ${ASMJIT_COMPILER_HEADERS})

Link_Libraries(AsmJit)

Add_Executable(testcompiler        ${ASMJIT_DIR}/test/testcompiler.cpp      )
Add_Executable(testcpu             ${ASMJIT_DIR}/test/testcpu.cpp           )
Add_Executable(testjit             ${ASMJIT_DIR}/test/testjit.cpp           )
Add_Executable(testjumptable       ${ASMJIT_DIR}/test/testjumptable.cpp     )
Add_Executable(testmemorymanager   ${ASMJIT_DIR}/test/testmemorymanager.cpp )
Add_Executable(testopcode          ${ASMJIT_DIR}/test/testopcode.cpp        )
Add_Executable(testrewrite         ${ASMJIT_DIR}/test/testrewrite.cpp       )
Add_Executable(testvariables       ${ASMJIT_DIR}/test/testvariables.cpp     )

Ještě než narazím na věci co mi vadí proberu základy. Hned ze začátku pomocí cmake_minimum_required(VERSION 2.6) říkám, že chci minimální verzi cmake 2.6, pokud máte starší verzi, zobrazí se warning a buď skript projde, nebo ne.

Jako další věc co je nutné udělat je vytvořit projekt, Project(AsmJit C CXX) znamená, že vytvářím projekt, který používá C a C++ překladač. Zde bych chtěl upozornit na první problém. Pokud vytvoříte jen C++ projekt (CXX) a použijete později například Include(FindThreads), tak váš skript skončí chybou (protože FindThreads potřebuje C překladač).

Následuje seznam souborů v projektu. Pro přidání souborů rád používám něco jako Set(ASMJIT_DIR "."), abych si usnadnil případnou refaktorizaci (zatím bylo potřeba 1x). Soubory se často rozdělujou na zdrojové a hlavičkové, protože ty hlavičkové je v linuxu možné pomocí make install nainstalovat (ukázkový skript to ale neobsahuje).

Až po sem je skript celkem přímočarý. Následuje část:

Include(FindThreads)
If(CMAKE_THREAD_LIBS_INIT)
  Link_Libraries(${CMAKE_THREAD_LIBS_INIT})
EndIf(CMAKE_THREAD_LIBS_INIT)

Která se mi nelíbí. Začnu tím jednodušším - člověk si musí pamatovat 2 věci k tomu, aby udělal jednoduchou detekci - Include(FindThreads) a CMAKE_THREAD_LIBS_INIT. Druhá věc co mi vadí je kód pro vytváření podmínek. Ukončovat podmínku pomocí EndIf() a vevnitř ji ještě zopakovat, kde to jsme?

Poslední věc co bych této části vytkl je to, že já už jsem z toho tak zmatený, že se mi stále daří udělat chybu v ${} (zapomenu na ${} nebo to tam dám navíc). Jasně, je to moje nepozornost, ale prostě se mi to stává.

Pokračujeme :) Dnes jsem doplňoval tuto věc:

If(${CMAKE_BUILD_TYPE} STREQUAL "debug")
  Add_Definitions(-DDEBUG)
EndIF(${CMAKE_BUILD_TYPE} STREQUAL "debug")

Při pohledu na ten kód je celkem jasné, co to dělá (přidá definici DEBUG pokud je build nastavený na debug). Zajímalo by mě, jestli je toto ta pravá cesta, a kolik lidí používající cmake by to napsalo z fleku bez použití manuálu. CMAKE_BUILD_TYPE proměnná se mi zdá jako jediná věc, co je na tomto kódu v pohodě. Podmínka je podle mě strašná, místo ${CMAKE_BUILD_TYPE} STREQUAL "debug" by se v jiném jazyce dalo napsat třeba CMAKE_BUILD_TYPE == "debug". Vím, že je to hodně podobné, ale není vám to bližší?

Ten zbytek kódu podle mě není třeba komentovat (vytvoření sdílené knihovny a testovacích aplikací).

V tomto zápisku mi jde hlavně o to, že cmake se používá asi nejvíc mezi C/C++ programátory (nebo ne?) a ta syntaxe mi přijde v této oblasti nepřirozená. Nejde mi jen o to, že to vypadá jinak, ale zkuste si v tom napsat něco složitějšího - funkci, která má vstupy a výstup a zkuste si tu funkci používat. Nebylo by rozumnější používat něco, co používá skriptování blízké k C/C++? Třeba ten poslední příklad by se v pseudo-javascriptu dal napsat takto (objekty jsem si vymyslel, nic takového neexistuje):

if (Global.buildType == "debug")
{
  Global.definitions.append("DEBUG");
}

Kdyby existovalo něco takového, tak bych asi neváhal ani sekundu:) Nejde mi jen o tu syntax, ale i o koncepci. Kdybych chtěl nějakou definici testovat, tak by stačilo napsat třeba takovou podmínku if (Global.definitions.contains("DEBUG") .... Kdybych šel ještě dál, tak si myslím, že pomocí EcmaScriptu by se daly psát i komplikovanější pluginy, třeba i na vytvoření makefiles a project IDE files. Radši ani nemluvím o tom, že podporu pro EcmaScript mají různé IDE přímo v sobě, takže kontrola syntaxe nebo našeptávání by mohla ještě víc zrychlit tvorbu skriptů.

Pokud používáte cmake, zkuste mi odpovědět v anketě, výsledky mě zajímají:)