> sokszor egy egyszerű Makefile nem elegendő, szükség lehet különböző feltételekre, ciklusra, stb. A szabvány szerint ilyenek a make-ben nincsenek. Persze meg lehet oldani különböző szkriptekkel, meg kétszeri make-hívással, stb., de praktikus, ha a build-rendszer ad erre közvetlenül lehetőséget. Természetesen ez nem azt jelenti, hogy egy egyszerű projekt (néhány C-fájl lefordítása, mindenféle trükkök nélkül) esetén helyesnek tartom mindenféle hype-build-rendszer használatát (akár egy ötször annyi ideig futó "autohell"-es ./configure-t is ideértek)
Részben egyetértek (
./configure), részben meg nagyon nem (build system).
IMHO a generalizált build system alapvetően egy rossz megközelítés, mert abból - kis rosszindulattal - kb. kétféle kategóriájú van. Az egyikbe tartoznak a fapadosak, mint a
make, meg az
mk, amik ugyan mentesek az agyhalál kategóriás függőségektől és megoldásoktól, mert tényleg csak annyit csinálnak, amennyit kell, viszont ahogy mondtad is, a bonyolultabb összefüggéseket nemigen lehet velük megoldani, jöhet a
./configure, ami vagy jól van összerakva, vagy nem, de leginkább nem (a pkg-configgal és hasonló retardált függőségkezelésekkel, stb.). A másikba pedig ezek az "univerzális" szörnyetegek, amik jellemzően több problémát kreálnak, mint amennyit megoldanak. Lassúak, bugosak, iszonyatosan bloatedek, hozzák magukkal a saját agyhalott függőségkezelésüket és az eredeti célt, hogy egyszerűbben buildeljünk, végül nem sikerül elérni, mert csak sokkal bonyolultabb lesz az egész és a végén már messze többet szopsz a rohadt buildsystemmel, mint nélküle. Ezek a rendszerek mindent meg akarnak oldani, mindent tudni akarnak, mindent is, ami lehetetlen és ennek megfelelően a saját dugájába dől a végén az egész koncepció. A
cmakeegyébként még hagyján, mert az csak simán szar, de ott a
waf,
scons, vagy a "kedvencem", a
meson, na azokat tényleg emberiségellenes bűncselekménynek kellene minősíteni. (Ahogy a Pythont is.) Csak önmagában a Python egy külön "kis" dependency hell-t jelent: egyrészt az egyik program buildeléséhez x.y verziójú Python kell (még mindig C/C++ források buildeléséről beszélünk), a másiknak x.y-2, a harmadiknak x.y+3; aztán ott vannak a különféle "subsystemeik", mint pl. a
meson-nál az az átokverte
ninja, amik a másik felét jelentik ennek a bizonyos Pythonos dephellnek, amiknek egy raklapnyi Pythonos "keretrendszer" kell, hogy futni tudjanak. Komolyan, gyorsabban elkészül az ember, ha fejben ártírja a C kódot assemblyre és nekiereszt egy assemblert, mint mire összereszeli ezt az óriáskígyókból összehányt spagettihalmot...
Na, ennek megfelelően az a megoldás, ami ténylegesen univerzálisan alkalmazható, az az, hogy írsz egy buildscriptet, ez ugyanis nem egy generalizált fos lesz, ami vagy jó a programodhoz, vagy leginkább nem, de azért ráerőlteted, hanem pontosan a programodhoz lesz szabva. Nem kellenek buildsystemek, de még makefile-ok sem; a scripted pontosan azt fogja csinálni, amit kell, azt, amit akartál, azt amit mondtál neki. És a buildscript az egyetlen, ami ténylegesen dependencyless, legalábbis az épeszűség keretein belül, hiszen shellnek és fordítónak mindenképpen lennie kell, különben amúgy sem fordítasz. (Oké, a
make, vagy az
mknem egy olyan kategóriájú függőség, amibe bele kell halni, de nem biztos, hogy az alaprendszer tartalmazza.) Igen, ez azzal jár, hogy akkor kell egy
shscript UNIX-ok alá, meg batchfile wincrap alá, meg mindenhova olyan, amilyen shell van, dehát a jó munkához idő kell. De egyébként meg, ha konzekvensen gondolkodik az ember, akkor előbb-utóbb amúgyis kialakítja magának a saját kis scriptalapú buildkörnyezetét, viszont nincs dephell, mert a buildscriptek ott vannak a forrásban, tehát a buildsystem - ha úgy tetszik - teljesen bundled. Nem függesz semmilyen külső szartól.
(És itt jegyezném meg zárójelben, hogy a sokak által lesajnált, állítólag elavult Pascal ökoszisztémát ezek a problémák marginálisan, vagy sehogy sem érintik; a komplex programok fordítási sebessége a sokszorosa a C/C++-nál tapasztaltnak, nincsen szükség hatvannyócezerféle függőségkezelésre, meg build systemre, ami mind máshogy szar, hanem elég a fordító, meg a különféle include directory-k. Persze igazság szerint ez C/C++ alatt is mehetne így (sőt, régen így is ment), de az ottani kúltúra egy sok másféle ökoszisztémát épített ki.)
> a subversion-os rész tárgyi tévedést tartalmaz (cow hiánya), ezért "sucks", a többi része szerintem szubjektív mintsem objektív vélemény
SVN-be nem másztam bele annyira, így ezt a részt - hozzáértés híján - inkább nem kommentálnám. Viszont azt furcsállom, hogy a Gitet ajánlják helyette alternatívának, amikor azért annak is van egy vagon marhasága... (#1, #2)
> egy konkrét ablakkezelőhöz írt szoftver (pl. "trash icon programs") miért lesz "sucks", ha a konkrét ablakkezelő által nyújtott plusz funkciókat kihasználja
Bocsánat, ők nem ezt írták. Azt írták, hogy az a "sucks", ami csak akkor működik rendesen, ha ezek a plusz funkciók elérhetőek. Senki nem mondta, hogy nem lehet opcionálisan használni őket, ha elérhetőek.
> nem tudom (értsd: nemigen értek hozzá), hogy ha valami C++-ban íródott, mennyire "sucks" (nekem úgy jön le, hogy ez már egy rossz pont)
A C++-t a szintaxisa miatt szeretik utálni, illetve manapság még a C++ ökoszisztémához társuló elbaszott függőségek és heavy-weighted framework-ök miatt is. (Pl. Qt5.) A szintaxis szeretete/utálata ízlés kérdése (én sem szeretem, de nem kapok tőle sikítófrászt, mint a Pythontól), a többi meg ugyan jogos, de nem konkrétan a nyelv hibája, hanem a körészerveződött közösség kúltúrájáé. Ami a CLang-ot illeti, kell hozzá
cmakeés Python is, hogy lebuildeljük. Ez azért bőven elég ahhoz, hogy a CLang buildelhetőségét a "sucks" jelzővel illessük. A GCC-nek meg Perl kell, az is rated WTF.
Viszont, hogy azért nézzük meg az érem másik oldalát is: a suckless brigád által javasolt TCC ugyan impozáns fordítási sebességgel bír, de egy fordítónál nem csak az számít, hogy ő maga milyen gyors a forgatásban, hanem az is, hogy milyen gyors lesz az, amit forgat és ez azért árnyalja kicsit a képet. Aztán ott van még a támogatott CPU-k kérdése is: a TCC x86 (és talán ARM) only, míg a CLang és a GCC egy tonna CPU-t támogat. OS-ek tózse, a TCC a saját doksija szerint Linux és windows only, míg a másik két fordító szinte minden platformon elérhető (főleg a GCC).
Egyszóval hiába van jól megírva a TCC és hiába nincsenek agyfasz függőségei, ha a felhasználhatósága erősen korlátozva van pár specifikus területre. Ezen adott feladatokra (ld. pár példát a linkelt wiki cikkben) céleszköznek pont jó, de drop-in replacementnek a GCC vagy a CLang helyére nem alkalmas, legyen bármekkora trágyahalom is az utóbbi kettő. (Egyébként tapasztalataim szerint usage és result szempontból a CLang egészen tűrhető, csak leforgatnod ne kelljen, mert jaj.)