SCons, il peggior build tool?

Disclaimer: questo post è una lamentela che mi sono tenuto dentro per tanto, troppo tempo, nei confronti di uno strumento. Per quanto possa essere strano prendersela con un programma, eccoci qua.

SCons è un build tool (fortunatamente) non troppo diffuso per C/C++. (forse può compilare anche altro, ma l’ho solo visto usato per C++). A differenza di strumenti come gli autotools, CMake o meson, SCons è pìù che altro una libreria python usata per sviluppare script che “guidino” la compilazione.

Background: oltre a mantenere Godot per OpenBSD, sto aggiornando SCons dalla 2.5.1 alla 4.2.0 e sistemando una decina di port che ne dipendono

Dopo aver litigato con SCons parecchio credo di aver realizzato perché non mi piace, ma anche di “oggettificare” i problemi che tale build tool ha.

Python non è una buona idea (per un build tool)

C e C++ hanno la fantastica proprietà di essere standardizzati e “stabili” (C molto più che C++). Questo significa che è possibile compilare codice di 10 anni fa *OGGI* senza grossi problemi. Certo, librerie di terze parti possono aver cambiato le interfacce nel mentre, ma le librerie di sistema in genere non cambiano così velocemente. Al momento attuale è ancora (più o meno) possibile usare python2, ma data la deprecazione sta sparendo (se non lo è già) dalla maggior parte delle distro. Questo significa che programmi perfettamente funzionanti diventano sempre più difficili da compilare per colpa del build tool.

Un esempio? L’ultima versione di Pingus (un giochino davvero carino!) è del Dicembre 2011. Usa SCons e python2, il che significa che da SCons 4 in poi non è più possibile compilarlo. Lo sviluppo sembra anche essersi fermato, il che può suonare triste ma alla fine il gioco è completo e funzionante. Fortunatamente ha solo bisogno di cambiare qualche ‘print’ in ‘print(…)’.

Pingus

Un altro esempio è DangerDeep, un gioco ancora più vecchio di Pingus (non ho trovato delle date, ma l’ultimo post sul blog è del 2011 e afferma che sono quasi 4 anni dall’ultima release, quindi… 2008/2009?). Python3 sembra essere molto più pingolo di python2 per quanto riguarda i mix di tab e spazi, ho finito col ri-scrivere lo SConstruct per poterlo compilare:

DangerDeep

Non è bene che i build tool siano troppo flessibili

Build tool come autotools, CMake o meson forniscono abbastanza corda per impiccarsi, ma in genere hanno delle “best practice” che la maggior parte della community segue. Questo è un grosso vantaggio per chi gestisce i pacchetti: non devono leggersi migliaia di righe di script per capire come configurare la compilazione. Le varie infrastrutture per la creazione dei pacchetti molto probabilmente sono già in grado di gestire la maggior parte degli aspetti, e il porting è semplice.

Con SCons, ogni progetto è un fiocco di neve: bello (?) ma unico.

Un build tool quindi, per essere utile tanto a chi pacchettizza il software che a chi lo scrive, deve cercare di essere il più schematico possibile.

Conclusione

Se stai per iniziare un nuovo progetto, considera di usare gli autotools o CMake piuttosto che SCons. Non farti ingannare dalla semplicità di scrivere qualche funzione in python piuttosto che in m4sh: il peso di un’apparente semplificazione iniziale verrà pagato dai maintainer e dagli utenti finali nel lungo periodo.

Una cosa però mi sento di dover lodare agli sviluppatori di SCons: sono riusciti a mantenere una (non aspettata da parte mia) buona retrocompatibilità. Ho aggiornato diversi port da scons 2 a scons 4 e il massimo che ho dovuto fare è stato rimuovere un paio di ‘env.SourceCode(".", None)’. Non male per un salto di ben 2 major release. Il problema principale è stato python2 -> python3, tra sintassi diverse e moduli rimossi (*coff coff* StringIO *coff coff*)

$BlogIt: scons-peggior-build-tool.gmi,v 1.1 2021/10/20 07:41:40 op Exp $