Originariamente inviato da antonellocaroli
"Una delle principali caratteristiche di questa distribuzione è che tutto si compila ed in fase di installazione due delle principali scelte da compiere sono:
CFLAGS
USE

Cosa sono le CFLAGS? Semplicemente una variabile che indica al compilatore C/C++ eventuali ottimizzazioni da effettuare in fase di compilazione. Scegliere le corrette CFLAGS non è una cosa semplice, come tutte le scelte è relativa all'obiettivo che si cerca di raggiungere (stabilità Vs prestazioni). Le CFLAGS dipendono anche dall'hardware su cui si sta operando.

Molti utenti [IMAO non utenti gentoo (o almeno non in modo permanente e/o cosciente)] credono che il migliore incentivo per installare Gentoo siano queste maledette ottimizzazioni. Ognuno di noi vuole una macchina scattante e veloce, Gentoo, anche se a spesa di svariate ore di compilazione, può garantirci questa meta.

Personalmente le CFLAGS non mi giusticano il prezzo del biglietto: si può guadagnare qualcosa da questo tipo di ottimizzazione, ma, in media, il sistema non risulta molto più scattante che con una normale distro binaria. Le CFLAGS non sono l'arma segreta. Quello che secondo me fa la differenza fra Gentoo e tutte le altre distro sono le USE.

Cosa sono le USE? Si può facilmente spiegarlo con un esempio: immaginiamo di voler installare il nostro player audio preferito e si supponga che la nostra libreria di file multimediali sia composta solo da file OGG. Anche se il nostro player supporta 8500 formati audio, a noi ne interessa solo uno. Con una normale distro binaria non c'è modo di discriminare le features che un determinato applicativo deve garantire, su Gentoo si può. Un player audio compilato per supportare un solo formato audio (contro 8500) probabilmente risulta più scattante. Applicate questa logica a tutto il sistema e capirete che l'ottimizzazione non passa solo per le CFLAGS (o LDFLAGS/etc).

Ma le USE ci vengono incontro anche per le dipendenze: se il mio player deve riprodurre solo MP3 probabilmente non avrà bisogno di altre librerie esterne (legate ad altri codec audio). Gentoo ti fa dimagrire il sistema.

Ma Gentoo è Gentoo e non si ferma solo qui. Non solo ci aiuta nell'applicare queste ottimizzazioni ma addirittura controlla che tutto l'accrocchio funzioni. Controllo (con eventuale risoluzione) sulle CFLAGS problematiche per alcuni applicativi, USE necessarie per una coerenza del sistema e molto altro ancora." Gentoo Linux: qui mica pettiniamo le bambole

Strumento Utile,per informazioni su pacchetti installati e non, per gentoo é eix https://wiki.gentoo.org/wiki/Eix

un esempio: eix squeezelite



ci da la versione aviable con le USE Flags/dipendenze disponibili e quella attualmente installata (se installata) e con quali USE flags é stata installata e quali evitati (quelle blu)...

Attenzione: "pa" in squeezelite è portaudio, non pulse audio. Per usare pulse audio (da evitare) basta installarlo e scegliere una opzione -o adeguata.

Non so da dove eix derivi le informazioni, ma sono errate (errore peraltro comune e diffuso).

La ebuild di gento per squeezelite (non so per le altre applicazioni) passa CFLAGS e USE al sistema di make mediante un opportuno makefile, prodotto mediante una patch delo standard, quindi da questo punto di vista non ha nessuna particolartà rispetto a qualsiasi altro sistema linux per il quale si compili squeezelite, che fa un uso DINAMICO delle librerie, quindi - eventualmente - maggiori benefici si possono ottenere compilando quelle o i diversi componenti di sistema, dipende da come sono architetturati, non ne ho idea, ma è altamente probabile sia così.

Per lo stesso motivo, sempre limitatamente a squeezelite, non c'è un reale risparmio di dimensioni (e quindi di memoria) includendo o escludendo delle librerie dalla fase di link (USE), anche se le si include (come header in compilazione) possono non essere residenti sul sistema (come librerie in fase di utilizzo), fino a che non si tenta du utilizzarle, quindi non provocano nessun appesantimento run time e nemmeno nessun reale incremendo di dimensioni del sistema se non si installano le librerie.

Non è detto sia così per gli altri players, questo non lo so.

Il vantaggio di escluderle in compilazione è che evita di dover 'inseguire' inutilmente delle dipendenze, semplificando le cose, ma lo stesso fanno, per esempio, le versioni "min" per debian.

Questo meccanismo è insito in squeezelite per i codecs e le funzionalità considerate 'opzionali' dal progettista, mentre quelle standard sono sempre presenti, se non che l'estensore della ebuild di squeezelite per gentoo ha deciso di modificare (mediante una patch) i sorgenti, non per una specificità o caratteristica di gentoo, ma solo come scelta di implementazione, che è possibile ma non indispensabile per qualsiasi OS, così che anche i codecs standard (flac e pcm) possono in teoria essere esclusi già dalla fase di link.

Verissimo è che per architettura di processore diverse è bene usare gli opportuni CFLAG, ma sempre, non solo in gentoo, così da utilizzare gli opportuni set di istruzioni e non costringere il SO ad 'emulazioni'. Quindi ARM e PPC andrebbero sempre compilati con i make specifici, tanto per squeezelite che per le librerie e gli altri componenti.

Anche in questo caso squeezelite ha il suo meccanismo 'standard' per gestire la cosa su tutte le piattaforme, nella ebuild per gentoo è stato realizzato in modo non compatibile (patch al makefile standard), ma ancora una volta è una scelta, non una necessità imposta da gentoo e men che meno una sua caratteristica.

Quanto sopra limitatamente a squeezelite, è ovvio che applicazioni o componenti meno 'flessibili' (es. link statici) beneficeranno maggiormente della 'compilazione su misura', producendo nel complesso un sistema più snello ed efficiente, che di certo male non fa.