Dotaz: CMake, pocet radku v souboru

[Franta]

Existuje nejake lepsi reseni, jak v CMakeLists.txt spocitat pocet radku v souboru, nez toto? Nacteni souboru a pak ukladani matchu do pole jenom proto, abych mohl ziskat jejich pocet, mi neprijde nejlepsi. Bude se jednat o velky projekt s hodne soubory a nechci, aby beh cmake trval vecnost:

file(READ ${source_file} source_file_contents)
string(REGEX MATCHALL "\n" newline_matches "${source_file_contents}")
list(LENGTH newline_matches newline_count)

---

---

Odpovědi

[Petr Šobáň]

wc -l soubor

[Franta]

Ja se omlouvam, ale myslici clovek snad pozna, ze tohle mi je k nicemu. Pisu v CMakeLists.txt, jako priklad uvadim nejake prikazy cmake a vy mi sem date konzolovy prikaz.

[Petr Šobáň]

A je problém ho použít že?

Když ho použít nechceš nemusíš o tom to je napiš si počítání konců řádků podle sebe.

[Franta]

Ale vsak pisu, ze to potrebuju v cmake a ne ve shellu.

[Kit]

Předpokládám, že cmake umí spouštět wc a shell k tomu není vůbec potřebný.

BTW: K čemu je vlastně dobré znát počet řádek ve zdrojovém souboru?

[kamen]

vy jste uplne ale uplne zaujaty tim wc.

dotaz byl jak to udelat v cmake.

ne na wc, ne v shelu,omv,aralu..

[Petr Šobáň]

Nejsem tím zaujatý pokud jsi si nevšiml další příspěvky nebyly moje.

Ale když už jsme u toho proč bych spouštěl nějaký shell????

cmake neumí spustit externí program.

A jinak taky by mě zajímalo proč v programu počítat kolik má řádků?

[kamen]

muj omyl: sory; a ne jako, ale fakt. muj nehezky komentar patril predchozimu diskuteru.

cmake ext. program: pokud vim, tak cmake pri generovani build systemu umi spustit ext. program. je to ale ve vetsine nevhodne, protoze to vytvari potrebu platformne zavisleho ext. programu.

[Kit]

O shellu přece vůbec nebyla řeč...

Používám make, ve kterém zcela běžně volám externí programy (bez shellu) a předpokládal jsem, že to v cmake bude skoro stejné.

[Franta]

Unity build. Ale protoze se jedna o velky projekt, chci limitovat celkovy pocet radku (tj. vsech includovanych cpp souboru) pro takto vygenerovany soubor, jinak by to sezralo vsechnu pamet a kompilator by umrel.

[Petr Šobáň]

Co je zase toto za blbost?

Velké projekty se skládají z menších prvků které se teprve potom slinkují a né že se udělá jeden cpp soubor v kterém bude:

<include> 1.cpp
<include> 2.cpp
.......
<include> 10000.cpp

[Franta]

To neni blbost. Prave, ze se sklada z mensich prvku, ty se skladaji z mraky cpp souboru a kdyz se kazdy kompiluje zvlast (i nekolik paralelne) tak to proste trva hodne dlouho. Unity build toto klidne dokaze zkratit na polovinu. Misto treba 200 cpp souboru kompilujete jen 20, ktere kazdy includuji 10 a samozrejme dale se to paralelizuje. Hlavni nevihodou je vetsi spotreba pameti pri kompilaci a proto se to snazim omezit celkovym poctem radku.

[Sten]

O ccache jste už slyšel? V porovnání s tím je Unity Build jen nepodařená hříčka.

[Kit]

Includují se přece jen hlavičkové soubory, které bývají poměrně krátké. Nějaké překročení limitní délky vůbec nehrozí.

[Franta]

V tomto pripade includuji cpp soubory do jineho cpp souboru, ktery se kompiluje misto tech puvodnich. Jak pisu vyse, pokud bych do jednoho souboru naincludoval vsechny, nebude dostatek pameti pro kompilaci, je potreba to nejak rozdelit a omezit to poctem radku tech cpp souboru je +- autobus uzitecne reseni. Akorat se jeste snazim zkratit dobu behu cmake.

[Kit]

Tohle řešení ve výsledku pouze prodlouží dobu kompilace, nehledě na hromadu dalších nevýhod.

[Petr Šobáň]

Přesně blbost.

Na začátku možná ušetříš při kompilaci jednoho velkého souboru než 1000 menších, ale pak při opravě jednoho řádku zase musíš přeložit jeden velký soubor než 1 malý.

Takže za mě je to fakt blbost o to co se snažíš.....

[Franta]

To je pro automatizovane buildy a ne pro vyvoj, kdy zmenim jednu radku a musim pak prekompilovat haldu souboru.

[Petr Šobáň]

Panebože takže vývoj máš dělaný jinak a finální překlady taky????

Bral bych to kdyby se to pak překládalo pro 1000 různých platforem, ale pro těch pár co existují?

Distribuji to pak jako binárku, a né že se to musí přeložit na každém stroji samostatně...

By mě zajímalo pro jakou firmu pracuješ že máš tolik času se zabývat kravinama a podle mě to kravina je.

[Franta]

To jsou automatizovane buildy pro ruzne vetve pro ucely automatickych testu. Nejsou to buildy pro finalni produkt. Tech vetvi neni malo a cim drive se to prelozi, tim drive se to otestuje, zjisti se pripadne chyby a opravi.

[Kit]

Ten článek je totální blud postavený na nesmyslech.

[Franta]

Zkousel jste to? Tak, jak je v clanku kod, tak je to samozrejme nepouzitelne na velky projekt, ale pri trose prizpusobeni se build da o dost zrychlit.

[Kit]

Nezrychlí, ale zpomalí. Když udělám změnu v jednom zdrojáku, zkompiluje se jen ten jeden zdroják a slinkuje s ostatními 199 již zkompilovanými soubory.

Podle toho článku když udělám změnu v jednom souboru, musím kompilovat všech 200 cpp souborů, což bude trvat mnohem déle.

[Petr Šobáň]

Je to blbost.

Protože při změně jednoho řádku musíš překompilovat jeden velký soubor než jeden malý a co bude rychlejší.......

A při vývoji se pořád mění nějaké věci a proč překládat všechno v jednom velkém souboru?

Možná při prvotním překladu ušetříš, ale při následných překladech budeš prodělávat....

[Franta]

Viz vyse. Kazdopadne pojdme se vratit k puvodnimu dotazu. Jak to prostredky cmake udelat lepe, bez spousteni externich nastroju.

[Petr Šobáň]

Prostě musíš ty řádky spočítat.....

Nevím co cmake umí a zjišťovat to nebudu, a nevím proč se bráníš používat externí programy.

Koukni do wc jak to počítá a implementuj postup na to co umí cmake.

[ssss]

Rekl bych, ze cmake nema zadny konkretni nastroj na pocitani radku...CMake/Language_Syntax tohle to celkem jasne objasnuje, ze i reseni, ktere jsi uvedl je v napsano jako script a nikoli funkce. cmake je nastroj na generovani souboru z jinych souboru, kontrolu zavislosti, substituce...

Mas tak asi moznost bud pouzit tu uvedenou funkci nebo zavolat externi nastroj. Ani jedna moznost me neprijde spatna. Pouziti funkce je vic multiplatformni, naopak externi utilita bude vic flexibilni.

Je treba si uvedomit, ze samotne cmake externi utility vola mnohokrat.. pri osahavani systemu na kterem bezi, u ruznych kompileru... testovani vlastnosti knihoven, prikazu...

Dal bych mel upozornit, ze dokud si clovek skutecne neosaha konkretni reseni ohledne vykonu, tezko muze delat obecne zavery. Systemy typu make, cmake jsou vesmes interprety, tedy bezi vyraznejsi pomaleji nez kompilovane veci. Pokud skutecne narazis na problem s vykonem, zjevne bude potreba sahnout k C/C++, Fortranu, Ada, a apod.

[stativ]

Přidám se k názoru, že je to blbost. Pokud chcete zrychlit build, tak se doporučuji spíš podívat po ccache a pokud ještě nepoužíváte, tak zkusit precompiled headers.

[Kit]

Myslím si, že další cache jsou již zbytečné a ke zrychlení buildu již nijak nepomohou.

[Ondra]

Článek je z roku 2009, kdy SSD byl přepychem horních deseti tisíc, případně předmětem vášnivých diskusí v anarchistických kroužcích. Místo podobných rovnáků na ohejbáky bych se raději soustředil na investici do rozumného disku (SSD), a do lepšího strukturování kódu, aby se při změně jednoho řádku nemuselo kompilovat tisíc souborů. Pak samozřejmě do paralelizace buildu; pokud byste chtěl hodně popustit uzdu fantazie, tak je možné rozdělit projekt do několika knihoven, které se budou buildit samostatně a na různých nodech, a finální produkt se jen poskládá z nich.