C okoszisztema tankonyv

Fejlesztés

Sziasztok!

Tudtok ajanlani olyan konyvet, ami a C programozas okoszisztemaval foglalkozik (Linux alapokon)? Olyan konyvre gondolok, ami altalanosan hasznalt eszkozoket, es praktikakat reszletezi. Pl. Build eszkozok (CMake, Makefile), unit teszt konyvtarak, bevalt konyvtar struktura stb.

Egyik feltetelem, hogy ne legyen IDE specifikus.

Magat a C nyelvet nem kell kifejtenie, arra van mas forrasom :)

( buccaneers v | 2022. 10. 04., k – 19:38 )

Pere László: Unix ​– GNU/Linux – Programozás C nyelven

Azt a C-t rust -nak hivjak ahol ilyesmit talalhatsz.

Nincs elterjedt kozosen hasznalt resz ezekre.
A C libeket linux distrok terjessztik, nincs egyseges elterjedt cargo.
Unit testeket mindenki ugy csinal ahogy akar.

Fordiasi flagak segitesere van a pkg-config.
Forditas managelesere sok tool van, Autotools talan legosibb viszonylag elterjedt.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Anno beleneztem a Rust-ba, es igazad van. Annal az okoszisztema majdnem a kezdetektol fogva jol definialt.

Igazabol a kivancsisag is hajt, hogy milyen egy jol megirt C program, illetve, hogy kepes vagyok-e menedzselni egy nagyobb projektet ezen a nyelven.

Eddig amiket irtam C-ben, az nem volt tobb par ezer sornal, es nagyjabol egy lepesben keszult egy vegrehajthato fajl.

A tervem, hogy egy modularis projektet irok, es a lehetoleg szeretnem jol elkezdeni.

Az autoconf-rol erintolegesen olvastam egy kb 10 oldalas leirast, hogy hogyan mukodik, de a Makefile generalasnal (compiler cserelesnel) tovabb nem nagyon jutott. Ha jol gondolom kicsit tobbet tud ennel.

Szerinted a CMake-kel vagy az autoconf-al erdemes inkabb foglalkozni?

Lambda calculus puts the fun into functional programming

https://mesonbuild.com/Simple-comparison.html
https://mesonbuild.com/Comparisons.html

autotools sok tanulast igenyel es lassu, de sok "regi" project hasznalja, mert sok-sok platfrom tamogatasa eseten ez egy jart ut.
Erdemes megnezni, mert valoszinuleg bele fogsz futni es lehet valamit bele is kell javitani.

Ha vegtelen +1 platfrom tamogatasa nem a fo cel, akkor massal probalkoznek.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Erdekes cikk.

Az en strategiam az, hogy azokat a reszeket, amik egyseget alkotnak azokat egy-egy .so fajlba rakom. Kb egy alprojekt lenne a projektben.

Az .so fajlra hivatkozo al- vagy foprojekt meg fuggeni fog az .so fajltol (de nem modositasi datumatol), es annak a fajlnak a publikus fejleceitol (vagyis nem mindegyik headertol).

Az kerdeses szamomra, hogy a modositasi datumot ki lehet-e iktatni a Makefile-ban, de ennek meg utananezek.

Lambda calculus puts the fun into functional programming

Koszi a linket.

Jo konyvnek tunik. Olyan teruletekkel foglalkozik, amikrol ugyan tudtam, hogy leteznek, de nem foglalkoztam melyebben veluk.

Kifejezetten hasznosnak tunik az strace fejezet, illetve a gdb-be is ugy tunik melyen belemegy (legalabbis gondolom, ha 80 oldal csak arrol szol)

Erdekel az is, hogy mi az ELF es a PIC (utobbirol nagyjabol csak annyit tudok, hogy kell az .so letrohozasahoz)

Lambda calculus puts the fun into functional programming

Wow, ez egy egész jó könyv. Jól össze van szedve benne, minden egy helyen. Bár azért vannak benne elavult dolgok, Gtk+-t kb. senki se használ már, de nem tartom kizártnak, hogy az ott írtak egy része használható még Gtk3-4-en. Ezen a ponton el is értük, amiért hozzászólok: az ilyen linuxos és fejlesztési témákat nem ajánlott könyvből tanulni. Ez egy régi világból visszamaradt beidegződés, hogy mindent könyvből, egy helyről összeszedve. Ma már olyan gyorsan változik, bővül ez az IT szakma, hogy a könyvek egyszerűen nem tudják tartani ezzel a lépést, mire a szerzők átírják, lektoráltatják, a nyomda tördeli, kiadja, terjeszteni, az évek kérdése, addigra elavul az update is benne. Ezt netről érdemes tanulni, meg gyakorlati példákat nézni, hogy pl. nagyobb projekteben hogy szól a Makefile, mit hogy oldanak meg.

Még ha valami elméleti alapról lenne is szó, pl. programozás alapjai, algoritmusok, C nyelv, azokat lehetne könyvnől, mert maga az elméleti alap nem nagyon változik, de a gyakorlati vonatkozások, meg ezeken felüli rész állandóan.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

unit -test frameworkot osszedobni xUnit outputal nem egy olyan dolog amiert egy C koder a szomszedba megy.
Ha konyvet irnal melyiket tenned bele ?

Melyik az elterjedt ?

BTW, coverage:
https://gcc.gnu.org/onlinedocs/gcc/Gcov.html

BTW, Van olyan C project ahol teszteket masik csoport irja , es nem is C -ben.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Oszinte leszek, nem irnek rola konyvet, de ha irnek is nem emelnek ki egyetlen frameworkot sem (talan a munit-ot hasznalnam peldanak), mert pont hogy nem a framework a lenyeg, hanem az elmelet/filozofia. 

Es igen, egy nagy projektnel joesetben van kulon test team aki megirja nem csak a unit de az autotesteket is. Sot meg csak nem is ok tesztelik hanem a ci pipeline. 

De en arra irtam hogy ha tanulni akar, akkor akkor egyszeruen felmegy a googl-re/github-ra/gitlab-ra es kivalaszt egyet es hasznalja. Jok a konyvek, de kb csak a tesztelesrol lehet irni egyet es van is sok. Es akkor nem beszeltunk mas kerdesekrol. Mert a fejlesztes ma mar nem csak annyi hogy kodot irok, ot van a teamwork, a scrum, ci/cd, sot a mai fjelesztok jo ha kepben vannak a containerekkel, felhokkel, tudja mi a queue management, stb., stb.

Elmultak mar azok az idok, amikor egy fejleszto megirt egyedul egy SAP-hoz hasonlo rendszert monolitikusan egy vastagkliensben evek alatt. 

De éppen azért kellene legalább egy útról könyv, hogy meg lehessen tanulni úgy, hogy nem kell ezer féle forrásból kitúrnod, hogy mit hogy kell csinálnom, ami ugye egy kezdőnek rémálom. Ugyan ezen okból kellene könyv a buildről is. Ezek olyan területek, amiken - lássuk be - egy sokat megélt profi is próbálkozgat, meg addig tákolja ameddig éppen nem kezd el működni, meg maga sem érti az éppen használt toolok teljes lelkivilágát.

Kezdőnek még rosszabb, nekik kellene egy kijárt út, amin csak végig kell menni. Aztán amikor már abban eligazodik, akkor megismerheti a többit is.

Hat erre vannak az egyes cegeknel a ramp-up-ok meg a mentoring. Magadtol megtanulni ezeket a dolgokat szinte mission impossible. Raadasul nem is biztos hogy kell, mivel megtanulsz valamit aminek majd a munkad soran semmi hasznat nem veszed. En azt mondanam, hogy inkabb olvass cikkeket a teged erdeklo temakban (dzone, medium) es majd ha kell akkor celiranyosan megtanulod amire tenyleg szukseged van. Vagy mar en vagyok tul oreg ahhoz hogy olyanba tegyek bele effortot aminek nem latom a megteruleset a befektetett energia alapjan :D

Azt gondolom hogy a filozofiaval es best practice-ekkel kell tisztaban lenni, a tobbi jon magatol, kenyszerusegbol :D

Ugy erzem van jelentosege annak, hogy milyen teszt keretrendszerrel kezdi a csapat a fejlesztest,. Kulonosen a C nyelvnel ugy latom, hogy rengeteg parameter van, amit figyelembe kell venni. Pl. van-e heap protection, leak detection, segfault handling, vagy egyeb modon kell a memoriat ellenorizni.

Tesztelestol fuggetlenul rengetegszer talalkoztam olyan projektel (Nem feltetlenul C) aminel utolag derult ki, hogy egy framework nem tamogat bizonyos muveleteket, vagy egyenesen szabotalja a fejlesztest.

Github/Gitlab/stb. projektek olvasasa, vagy a lmgtfy szamomra nem segit a megfelelo eszkoz kivalasztasaban, ezert nyitottam ezt a forumtemat.

Per pillanat sajat keszitesu teszt frameworkkel dolgozom, ami implementalja az xUnit alapveto fuggvenyeit (assertTrue, assertEquals, setUp/tearDown), meg valgrind-al ellenorzi a memoriat, de optimalisabb lenne egy rendes teszt kornyezet.

Van rengeteg konyvem arrol, hogy mit kell elernem, hogy egy projekt sikeres legyen (Agilitas, Task/card management, CI/CD). Ezek mind hasznosak abban, hogy megertsem mi az ami hianyzik a projektbol, de minden programnyelvben mas eszkozoket kell hasznalni, hogy a konyvben leirtakat alkalmazni is lehessen.

Lambda calculus puts the fun into functional programming

https://llvm.org/docs/CommandGuide/llvm-cov.html

Nem csak coverage reporta jo,
ez (szomszedai) alapjan maga a fordito is tud optimalizalni, illetve neked is van egy profil-od arrol hogy merre megy el az ido.
https://en.wikipedia.org/wiki/Profile-guided_optimization

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem tudtam, hogy letezik projekt CMake, autoconf meg make osszefogasara. Mindenkepp belenezek.

Van esetleg arrol tapasztalatod, hogy ez a flow leirhato-e benne?

- build .so file

- unittest .so files

- generate report

- build executable (combine .so files)

Valamint a unit teszt eseteben a fuggosegek mockolasara van-e lehetoseg mondjuk az LD_LIBRARY_PATH allitgatasaval?

Lambda calculus puts the fun into functional programming

( Foltos | 2022. 10. 06., cs – 12:06 )

Könyvet nem tudok ajánlani, de nálunk kb. az alábbi van. (FW project vagyunk, de van egy linux API shared library -nk, és pár linux demo és teszt alkalmazásunk is.) Sajnos a C/C++ régi nyelv. A modern nyelvek alapból integrálják az évtizedes tapasztalatokat, ez itt nyilván hiányzik.

  • dependency management (high level): a nem közvetlen függőségekre google repo tool. Ez össze tudja szedni a magas szintű komponensek megfelelő verzióit git -ből.
  • Szoftver integráció (high level): két rendszerünk van. Egy makefile alapú illetve yocto. Mindkettő külső kényszer. Egy sima linux -os programnak nincs ilyen igénye. (Milyen konfigra milyen paraméterekkel kell kernelt, egyebeket fordítani témakör.)
  • dependency management + integráció: közvetlen függőségeket CMake FetchContent -tel szedjük le, de tudunk már leszedett forrást sőt, előre buildelt bináris is használni. Ezek főleg static library -k. Minden függőség "binárisát" integráljuk, azaz ha a project buildeli, akor az "configuration time" tötrénik.
  • build tool: CMake gnumake generátorral. Vannak függőségeink amik csak gnumake -kel fordulnak, így ez kötött. A CMake sok szempontból borzalamas, de kb. szabány tool lett elterjedtsége miatt, és sok szempontból jobb mint a sima gnumake.
  • compiler: GCC (jön majd clang)
  • Elődleges nyelv: C11 és c++11 (jön majd rust)
  • ccache -t használunk, a build -ek gyorsitására
  • coding style: checkpatch, clang-format, és editorconfig -ot használunk. LCS alapon dolgozunk, mert elég jó, és nem kell vitatkozni  senkivel miért úgy formázunk ahogy.
  • static analyser: cppcheck egyelőre, de lesz majd coverity. Illetve a GCC warning flagjei.
  • Dokumentácio: Sphinx + plantuml plugin + cmake domain plugin. Vannak doxygen kommentjeink, de doxygen egyelőre nincs. Dokumentációt readthedocs.io -n publikaljuk.
  • text editor: amit akarsz :) (vscode, eclise, vi és emacs)
  • version control: git (command line git + gitk + git-gui + tig + meld)
  • automation: "független" szkript halmazunk van. bash, python3, jinja2, gnumake, (expect (TCL)). Ezeket lehet futtatni kézzel, git-hook -ból és jenkins -ből.
  • unit teszt: CppUTest -et hasznalunk. Ehhez van CMake alapu integracios framework -un, illetve egy in-house python tool (c-picker), ami clang segitsegevel tud kodot, valtozókat másolni a teszt forrásba. Így a láthatósági korlátok feltörhetőek teszteléskor azaz akár static függvényeket is körbe tudunk mock -olni. gcov/lcov test coverage -et tudunk mérni.
  • test strategy: UT: PC -fut, component-test PC és targeten is fut, system: csak targeten. Mindenhez CppUTest -et hasznalunk, de component és system szinten nincs mocking. A kódot úgy írjuk, hogy tesztelhető legyen, de ahol kell ott c-picker -rel UT szinten tudunk garázdálkodni. Emulációban akár system teszt szinten is tudunk coverage -t mérni, de ez nagyon költséges (lassú).
  • code-review & repo management: gerrit + gitweb/cgit
  • CI: jenkins. Vannak szkriptjeink gerrit<->jenkins integraciora.
  • kommunikació: mailing list (elosztott, visszanézhető, mindenhol megy, szabad, titkosítható és biztonságos amikor kell).
  • ticketing: mailing list (jobb lenne egy "rendes webes" rendszer, de ez van). (Van belső céges jira, de ez inkább reporting és capacity planning célra).
  • build-environment menedzsment: saját szkript halmaz + docker/vagrant. A szkript halmaz helyett pl. nix csomagok jobbak lennének, de nincs erre erőforrásunk.

Open-source project vagyunk, igyekszunk nyílt toolokat használni. Nem állítom, hogy nincsenek jobb toolok a fentinél, de open-source -ban jelenleg ez egy élhető rendszer.
Biztos kihagytam ezt-azt, de nagy vonalakban ez a "szabvány" környezet.

Pár további gondolat:

  • Jó lenne egy csomagkezelő a függőségek és a build-environment kezeléséhez. Conan, Nix egyebek.
  • A yocto támogatásunk gyerek cipőben jár (nem ismerem). Szerintem ha teheted nem mész yocto közelébe.
  • Jó lenne egy egyszerű key-value storage tool. "Fingerprintelnénk" az egyes komponensek verzióját + build konfigját, a value meg a bináris lenne. Ezeket kellene hatékonyan menedzselni.
    - Egy csomagkezelő nyilván erre is jó lehet.
    - A yocto tud ilyet, csak nem tudom meg lehet e úszni a teljes ökoszisztémát.
    - Valójában a ccache is hasonló, esetleg rá lehetne gányolni a célra, ha fölé tennénk egy szkript réteget.