# [RFC][PORTAGE] Implementare /etc/portage/package.cflags

## FonderiaDigitale

Salve a tutti.

Sto creando un'implementazione in bash nella stessa modalita di package.use, ma per le CFLAGS, visto che manca in portage e gli sviluppatori si sono espressi in senso negativo sulla possibilita' di farlo (ma a me serve, visto che uso normalmente ~x86 e gcc versione unstable, e mi trovo spesso pacchetti che non compilano causa CFLAGS troppo spinte o errori di programmazione nei pacchetti stessi).

Avrei pero' bisogno di un paio di pareri su come implementare la cosa; ho un paio di possibilita' su come farlo.

Premesso che la sintassi base di /etc/portage/package.* rimane, ossia

```
categoria/pacchetto parametri

>=categoria/pacchetto-versione parametri

>categoria/pacchetto-versione parametri

<categoria/pacchetto-versione parametri
```

pensavo di implementare la parte dei 'parametri' in queste possibili vie:

```
-"singola CFLAG" "singola CFLAG"
```

allo stesso modo per cui una USE negata equivale a non usarla, mentre non-negata equivale a un +, ovvero a usarla.

La parte da sottolineare e' che in questo caso 'non usarla' significa STRIPPARE VIA la flag presente nel make.conf!

Ovviamente, strippando via le virgolette...

Quindi, per fare un esempio, supponendo di avere nel make.conf:

```
CFLAGS="-march=pentium3 -O3 -pipe -ftracer -fomit-frame-pointer"
```

e nel file /etc/portage/package.cflags

```
>=media-video/xine-ui- --O3 -fweb --ftracer
```

diverra':

```
CFLAGS="-march=pentium3 -pipe -fomit-frame-pointer -fweb"
```

Casi particolari:

la presenza di un '-march=qualcosa' rimpiazza quello globale, mentre '--march=esatta_architettura_del_make_conf' lo toglie

Stesso principio come sopra per mtune,mcpu

Stesso principio di cui sopra per O3,O2,Os,O1

tornando all'esempio di cui sopra:

se io avessi aggiunto al mio file -march=pentium2, sarebbe:

```
CFLAGS="-march=pentium2 -pipe -fomit-frame-pointer -fweb"
```

se avessi (secondo me per errore),  aggiunto al mio file --march=pentium2, non sarebbe cambiata l'architettura affatto

ma invece se avessi aggiunto al mio file --march=pentium3, avrei completamente non specificato l'architettura nelle mie CFLAGS per quel pacchetto.

Spero di non essere stato troppo criptico.

sono graditi suggerimenti precisi e con esempi, o comunque considerazioni costruttive.

grazie

----------

## doom.it

L'idea è buona, ti lancio solo una proposta, anche se il meccanismo dello "strip" mi piace.

Ricordando la regola K.I.S.S. secondo me il formato potrebbe essere semplicemente 

```

>=media-video/xine-ui  "-march=pentium3 -pipe -fomit-frame-pointer -fweb"

```

più che altro per una questione di semplicità: metti per esempio che ci sia una modifica alle CFLAGS nel make.conf, dovresti rivedere tutti gli strip... per capirci:

se prima ho:

```

CFLAGS="-march=pentium2 -pipe -fweb"

```

e voglio come risultato per un certo pacchetto 

```

CFLAGS="-march=pentium3 -Os -pipe -fomit-frame-pointer -fweb"

```

la sintassi con lo strip sarebbe:

```

=categoria/pacchetto  --march=pentium2 -march=pentium3 -Os -fomit-frame-pointer

```

ma se poi cambiassi le cflags in make.conf in

```

CFLAGS="-march=pentium2 -O2 -pipe"

```

volendo mantenere lo stesso risultato

dovrei andare a cambiare il file package.flags in

```

categoria/pacchetto --march=pentium2 -march=pentium3 --O2 -Os -fweb -fomit-frame-pointer

```

pensa dover rifare sto lavoro ogni volta per tanti pacchetti.... fastidioso no?

----------

## xchris

io preferirei un sistema doppio e con sintassi diversa (a mio avviso + leggibile)

-come sintassi per la parte cflags preferirei l'inclusione nelle parentesi per maggior leggibilita'. (infatti nel tuo post non avevo letto inzialmente il doppio "-"  (--ftracer)

suggerisco un modo di funzionamento alternativo per operare:

-assoluto

-relativo

Il primo da utilizzare per specificare esattamente le cflags che si vogliono

atom +(cflags)

il secondo per modificare quelle di default

atom default +(cflags) -(cflags)

Sarebbe anche carino poter definire dei profili corrispondenti a tuple in un  file /etc/portage/cflags.profiles

```

profilo1 cflags1

profilo2 cflags2

.

.

```

A quel punto nel tuo file originario si potrebbe mettere:

atom [Profilo] +(cflags) -(cflags)

Spero di non essere stato + criptico  :Smile: 

Ciao e buon lavoro! 

P.S.: bash?pythone?modo di integrazione?

----------

## fedeliallalinea

Come dice doom.it anche io preferirei la sintassi

```
>=media-video/xine-ui  "-march=pentium3 -pipe -fomit-frame-pointer -fweb" 
```

Dove quello tra " " rimpiazza tutto quello del make.conf

----------

## gutter

Io credo che l'idea di xchris non sia male. 

La sintassi con i due meno inziali la trovo poco leggibile.

----------

## neon

Io sono con fedeli e doom.

Meglio specificare le cflags assolute che dei - o +

Per il resto come pensi di implementarlo? patch a portage?

----------

## FonderiaDigitale

xchris: si vede che usi troppo python  :Razz: 

cmq l'idea la vedo positiva, ho qualche dubbio sul discorso dei profili: a che potrebbero servire secondo te?

Tecnicamente parlando (e si vede che l'hai partorita cosi perche programmi) l'idea di xchris e' piu facilmente realizzabile.

mi e' venuta un'ulteriore idea su un ulteriore approccio (forse opposto a quello di christian) su come implementare la cosa: semplifiicare l'aggiunta della sintassi e deputare tutto a un algoritmo.

Paradigmi (ricordiamoci che le flags, almeno IMHO, dovrebbero essere specificate nella forma naturale, ovvero con -cflag):

Se viene specificata una tra queste: march, mcpu, Ox, nel caso siano GIA' presenti nel make.conf, vengono tolte; nel caso siano presenti ma con valori diversi (es. nel make.conf -march=i686 e qui -march=pentium2), il loro valore viene rimpiazzato.

Per le altre cflag, se sono presenti in globale, vengono tolte, altrimenti aggiunte.

C'e' un problema ulteriore: togliere una cflag [n]non[/b] equivale a negarla. io posso non specificare nelle mie ${CFLAGS} -fPIC, ma cio e' ben diverso da negarla tramite -fno-PIC. bisognerebbe prevedere anche questo.

In sostanza si potrebbe trovare un'implementazione teorica del tipo :

+atom o atom: aggiungi o rimpiazza la cflag

-atom: togli la cflag se presente

~(atom):nega il valore della cflag (nella forma -fno-PIC) e rimpiazzala se presente (non valida per O,march,mtune,mcpu), se la flag specificata e' gia' negata, ad es. -fno-PIC, viene negata e torna positiva, ovvero -fPIC.

il valore di atom potrebbe essere specificato (esempio -fPIC):

+(-fPIC) -(-fPIC) ~(-fPIC)

+fPIC -fPIC ~fPIC

L'implementazione e' in bash, piu che altro x non includere ulteriori file esterni.

Esempio reale di uso secondo questo schema:

```
x11-base/xfree -fPIC +ftracer march=pentium4 +O3 ~finline-functions
```

----------

## Benve

 *neon_it wrote:*   

> Io sono con fedeli e doom.
> 
> Meglio specificare le cflags assolute che dei - o +

 

Più che altro dovrebbe essere più semplice da implementare e forse anche da usare

 *neon_it wrote:*   

> 
> 
> Per il resto come pensi di implementarlo? patch a portage?

 

Non credo che una patch sia una buona idea

----------

## FonderiaDigitale

non e' una patch, tutto verra' incluso semplicemente in /etc/portage/bashrc.

----------

## n3mo

Forse vado controcorrente ma preferivo l'idea primigenia, -- e -, una volta abituati all'uso delle cflag viene naturale enunciarle nella forma -cflag........chi non ha mai provato ad usare il tab mentre scrive un post scagli la prima pietra.

----------

## gutter

 *FonderiaDigitale wrote:*   

> 
> 
> [CUT]
> 
> [*]~(atom):nega il valore della cflag (nella forma -fno-PIC) e rimpiazzala se presente (non valida per O,march,mtune,mcpu), se la flag specificata e' gia' negata, ad es. -fno-PIC, viene negata e torna positiva, ovvero -fPIC.
> ...

 

IMVHO credo che questa funzionalità sia superflua nel senso che incasinerebbe un poco l'uso senza aggiungere niente di realmente necessario. 

Sempre IMHO. Non ho voglia di criticare ma solo di commentare  :Smile: 

----------

## fedeliallalinea

 *gutter wrote:*   

> IMVHO credo che questa funzionalità sia superflua nel senso che incasinerebbe un poco l'uso senza aggiungere niente di realmente necessario. 

 

Non e' vero visto che piu' di una volta dei programmi non accettavano delle flags, tipo dr-scheme che con -pipe non si compila

----------

## gutter

 *fedeliallalinea wrote:*   

> 
> 
> [CUT]
> 
> Non e' vero visto che piu' di una volta dei programmi non accettavano delle flags, tipo dr-scheme che con -pipe non si compila

 

Usi la sintassi esatta al posto di ~cflags.

----------

## randomaze

 *neon_it wrote:*   

> Io sono con fedeli e doom.
> 
> Meglio specificare le cflags assolute che dei - o +
> 
> Per il resto come pensi di implementarlo? patch a portage?

 

Mi aggiungo all'elenco allora.

Il colpo d'occhio sui pacchetti permette subito di capire la CFLAGS... almeno questo vale per chi (come me) ha una linea di CFLAGS relativamente piccola e nomale.

Ma capisco che chi ama avere una line CFLAGS talmente lunga da sovrascrivere interamente l'-march potrebbe non gradire la cosa...

----------

## FonderiaDigitale

randomaze: non ti seguo .. cosa intendi?

----------

## xchris

 *FonderiaDigitale wrote:*   

> xchris: si vede che usi troppo python 
> 
> cmq l'idea la vedo positiva, ho qualche dubbio sul discorso dei profili: a che potrebbero servire secondo te?
> 
> 

 

ad esempio si possono creare 2 profili (default e' quello del make.conf)

-default

-aggressive

-safe

la prima e' quella generica...

la seconda per applicazioni che effettivamente traggono beneficio da cflags spinte

la terza magari per i pacchetti in system (magari tutti in i686 per essere sicuri che il sys fara' sempre il boot anche dopo un cambio di processore)

diciamo che l'utilizzo dei profili sarebbe una via di mezzo tra lo stato attuale e le cflags specifiche per ogni singolo pacchetto.

chiaramente e' solo un idea  :Smile: 

ahem... si mi hai beccato... +(cflags) e' comodo da parsare  :Smile: 

----------

## randomaze

 *FonderiaDigitale wrote:*   

> randomaze: non ti seguo .. cosa intendi?

 

```
nomepacchetto FULL_CFLAGS
```

se la FULL_CFLAGS che vuoi dare al pacchetto é solo "-march=i686 -O3" non sarebbe un problema, con un colpo d'occhio vedi tutto.

```
net-p2p/mldonkey        -march=-i686 -O2

media-sound/gnomad   -march=i686 -Os
```

Se invece FULL_CFLAGS é qualcosa tipo: "-march=i686 -O3 -pipe -fforce-addr -fomit-frame-pointer -funroll-loops -frerun-loop-opt -frerun-cse-after-loop -falign-functions=4", e magari differenzia solo per quel -O3 che diventa -Os, il tutto in un'elenco di un centianio di pacchetti... in quel caso il colpo d'occhio non serve a molto... e una versione "relativa" in cui specificare solo la flag differente sarebbe meglio indicare solo le differenze con la CFLAGS normale, quindi:

```
net-p2p/mldonkey        -O2

media-sound/gnomad            -Os
```

ovvero considerando solo la possibilitá: "atom" e mettendo da parte i + e i -, almeno per le prime versioni (poi, con i primi feedback potresti vedere come evolvere la cosa...)

....sono stato piú chiaro? Se no la colpa é del mio stomaco che reclama e mi disturba  :Razz: 

----------

## FonderiaDigitale

per lo piu sono d'accordo con randomaze, con l'eccezione che ho presentato di aggiungere i ~..

----------

## Apetrini

Volevo chiedere se c'è un modo per personalizzare le CFLAGS di ogni singolo pacchetto? mi sembra al quanto limitante dover usare le stesse CFLAGS per tutto il sistema!!

è ovvio che potrei cambiare il make.conf di volta in volta, ma non è il massimo come soluzione.

Questa cosa dovrebbe essere utilissima, poiche permetterebbe di ottimizzare al massimo il sistema scegliendo le CFLAGS piu appropriate per ogni pacchetto.

Gia il fatto di usare -Os e -O3 insieme dovrebbe essere una gran cosa, alcuni rendono di piu con -Os altri piu con -O3, poi su alcune app vorrei -fPIC su altre no e cosi via ....

Spero che in gentoo ci sia un modo per fare cio....

----------

## .:chrome:.

certo che si può, ma devi specificarle A MANO quando fai l'emerge, e lo devi fare per ogni pacchetto.

personalmente non credo che si possano avere vantaggi apprezzabili in merito. di certo il gioco non vale la candela

----------

## Apetrini

a mano?

che pacco!! non c'è un file tipo quello per le use personali di ogni pacchetto? perche pensi che non ci siano vantaggi? mi sembrava che jackass fosse stato fatto proprio con questa filosofia!!!!

Scusa ma è ovvio che per firefox è meglio -Os perche ci mette meno a caricarlo (circa 3/4s in meno), am per un scco di altre app -Os fa schifo.

L'idea mi è venuto leggendo un post di "comio" riguardo le prestazioni gentoo, se vuoi capire il perche ti rimando ahttps://forums.gentoo.org/viewtopic-t-273079-postdays-0-postorder-asc-highlight-debian-start-25.html a pagina 2 cerca il commento di "comio".

----------

## .:chrome:.

 *Apetrini wrote:*   

> Scusa ma è ovvio che per firefox è meglio -Os perche ci mette meno a caricarlo (circa 3/4s in meno), am per un scco di altre app -Os fa schifo.
> 
> L'idea mi è venuto leggendo un post di "comio" riguardo le prestazioni gentoo, se vuoi capire il perche ti rimando ahttps://forums.gentoo.org/viewtopic-t-273079-postdays-0-postorder-asc-highlight-debian-start-25.html a pagina 2 cerca il commento di "comio".

 

si chiama effetto placebo. le dfferenze tra le CFLAGS le vedi su grandi cluster o quando dai in pasto al computer calcoli complessi.

nel caso specifico di firefox, soprattutto, non sono necessari calcoli complessi, quindi la compilazione -Os impiega solo più tempo, in qunato più complessa, e produce come unico vantaggio un eseguibile più piccolo. l'incremento di velocità che deriva dalla lettura di un eseguibile più piccolo è ottenibile in atri modi, molto meno macchinosi.

considera poi che non sempre sei libero di scegliere le CFLAGS che vuoi. è possibilissimo che il codice non funzioni con alcune di queste, tanto è vero che i pacchetti più grandi MASCHERANO le CFLAGS, imponendo quelle scelte dallo sviluppatore.

alla luce di questo, sei davvero sicuro di poter scegliere le flag che vuoi?

----------

## bender86

 *Apetrini wrote:*   

> Scusa ma è ovvio che per firefox è meglio -Os perche ci mette meno a caricarlo (circa 3/4s in meno), am per un scco di altre app -Os fa schifo.

 

Ma firefox non è una di quelle applicazioni che vengono compilate con C(XX)FLAGS sicure, decise dai programmatori, infischiandosene di quelle presenti nel make.conf?

Comunque anche secondo me sarebbe una buona idea poter compilare ogni pacchetto con flag diverse, soprattutto per pacchetti poco stabili con flags spinte.

----------

## Apetrini

@k.gothmog:

Guarda ti dico solo questo, io non lascio le flag di default neanche per la compilazione del kernel, ma sperimento sempre roba nuova. Vorrei avere la possibilità di "forzare" le CFLAGS che voglio io assumendomi tutti i rischi...

@bender86:

mi pareva che compilava con -Os ...

----------

## kaosone

sarebbe davvero ultile... alcuni pacchetti vanno notevolmente piu' veloci con cflags spinte 

per esempio tutti  i motori di rendering con cflags a puntino riducono i tempi di rendering anche di un terzo 

poi potremmo fare un wiki con tutt le cflags migliori pacchetto per pacchetto

ci pensavo anche io da tempo a questa opzione

----------

## comio

 *Apetrini wrote:*   

> @k.gothmog:
> 
> Guarda ti dico solo questo, io non lascio le flag di default neanche per la compilazione del kernel, ma sperimento sempre roba nuova. Vorrei avere la possibilità di "forzare" le CFLAGS che voglio io assumendomi tutti i rischi...
> 
> @bender86:
> ...

 

ci vorrebbe qualcosa tipo /etc/portage/packages.cflags o roba simile. magari con una sintassi del tipo:

```

>=app-emulation/vmware-linux-tools-5.0.0 "-O3 -f..."

```

magari è implementabile un po' come le packages.use o .mask.

Una cosa: Ribadisco il diritto di beta-testing!

Poi una cosa... comio senza apici  :Very Happy: 

ciao

----------

## Apetrini

 *kaosone wrote:*   

> 
> 
> poi potremmo fare un wiki con tutt le cflags migliori pacchetto per pacchetto
> 
> ci pensavo anche io da tempo a questa opzione

 

da oggi sei il mio mito, accidenti è proprio quello che ci vuole, magari non per ogni cavolata, ma per condividere esperienze su pacchetti piu grossi...

 *k.gothmog wrote:*   

>  l'incremento di velocità che deriva dalla lettura di un eseguibile più piccolo è ottenibile in atri modi, molto meno macchinosi. 

 

ehm scusa la curiosità ma quali sarebbero questi modi meno macchinosi?

 *comio wrote:*   

> ci vorrebbe qualcosa tipo /etc/portage/packages.cflags o roba simile. magari con una sintassi del tipo: 

 

sarebbe un ottima cosa.

----------

## randomaze

 *comio wrote:*   

> ci vorrebbe qualcosa tipo /etc/portage/packages.cflags o roba simile. magari con una sintassi del tipo:

 

Se non ricordo male FonderiaDigitale voleva implementare qualcosa di simile, e c'é stato anche un thread in cui si discuteva della sintassi da adottare

----------

## .:chrome:.

 *Apetrini wrote:*   

> ehm scusa la curiosità ma quali sarebbero questi modi meno macchinosi?

 

- usare file system che minimizzano gli accesso su disco facendo ampio uso di buffer in RAM

- ottimizzare gli accessi alla memoria configurando opportunamente i meccanismi di prefetching

- utilizzare sistemi di tuning delle memorie di massa (hdparm)

- scegliere un buono scheduler di I/O e ottimizzare il bilancio tra accesso sincroni ed asincroni

sono tutte cose relativamente semplici da fare.

quello che non capisco è che tipo di vantaggi pensi siano ottenibili dalla scelta di diverse flag per ogni pacchetto. pensi davvero ci sia differenza?

----------

## Apetrini

Attualmente uso XFS.

hdparm è settato in maniera ultra spinta.

di solito uso deadline, se no cfg.

Be se il progetto jackass esiste ci sarà un motivo, se possono farlo loro perche non posso farlo io.

e comunque la tua soluzione non mi sembra piu semplice di un -Os. Se per te queste cose sono semplici perche non fai un HOWTO che sono tutto orecchi. Vorrei che tu facessi l'HOWTO soprattutto su

```
 ottimizzare gli accessi alla memoria configurando opportunamente i meccanismi di prefetching 
```

se sei capace perche non contribuire alla comunità...

----------

## .:chrome:.

se usi XFS sei già a cavallo. è flessibilissimo.

si tratta di dare andare a smanettare sui parametri del file system (si trova tutto in /proc). tra questo e una opportuna scelta dello scheduler ed una buona (non spinta) configurazione di hdparm dovresti ottenere ottimi risultati.

tieni conto di una cosa però: non so se ti interessa, ma io per esperienza ho visto che le configurazioni spinte portano il risultato opposto a quello che si vuole. meglio configurazioni più conservative. se pretendi troppo finisce che guadagni 10 da una parte e perdi 100 dall'altra.

non faccio un HOWTO perché sono dell'idea che in queste cose non si debba mettere le mani se non le si conosce, poiché si tratta di componenti molto delicati del sistema. queste cose le lascerei a chi sa almeno cosa si trova davanti.

inoltre si tratta di soluzioni specifiche per ogni sistema. scrivere un HOWTO vorrebbe dire produrre un documento che funziona sul mio computer e rallenta gli altri... se ti avventuri in un livello così basso purtroppo queste cose le devi sapere

----------

## thewally

 *Apetrini wrote:*   

>  *kaosone wrote:*   
> 
> poi potremmo fare un wiki con tutt le cflags migliori pacchetto per pacchetto
> 
> ci pensavo anche io da tempo a questa opzione 
> ...

 

Si, ci avevo pensato anch'io   :Wink: 

Sembra sia necessario un TOOL....

Bisognerebbe rimboccarsi le maniche e fare un programmino che si curi di queste cose, magari un wrapper per emerge che ti consenta di specificare tipologie diverse di flag. Magari dandoti, talvolta, delle dritte, consentendo di creare schemi fissi tra i quali scegliere.... E (visto che sono in vena di esagerazioni) con una bella interfaccia alla "aptitude"...  :Very Happy: 

Sarebbe un sogno   :Wink: 

Qualcuno vuole tirare giu' un wiki con tanto di progetto?

----------

## Apetrini

@k.gothmog:

guarda che quando parlo di roba spinta, intendo roba che corre piu velocemente del normale, non per forza si tratta di roba ultra instabile, se in certi pacchetti -O2 corre di piu di -O3 allora per me 

il pacchetto è spinto se usa -O2. Poi uso XFS e i suoi parametri li configuro con laptop_mode_tools(ehm uso il portatile per fare esperimenti) che permettono di specificare tutte le opzioni XFS.

comuqnue mi piacerebbe(come ho scritto sopra) che mi dessi qualche informazione su 

```
ottimizzare gli accessi alla memoria configurando opportunamente i meccanismi di prefetching

```

 che meccanismi sono e da cosa sono effetuati... in pratica come si fa ad avere questi meccanismi? cosa li gestisce? ci sarà un metodo un tool, qualcosa....puoi darmi un informazione valida con la quale io poi mi possa arrangiare da solo?

P.s. scusate per [OT].

Per quanto riguarda quello che dice thewally, bè non saprei, non sono un  gran programmatore(anzi proprio per niente) quindi non mi espongo. Certo che però sarebbe bello che fosse gia implementato in portage. Ma cosa bisognerebbe fare per proporre ai sviluppatori gentoo di implementare una roba del genere? Forse dovremmo implementarla noi e poi proporla agli altri?

Comunque qualcuno che ne sa qualcosa si faccia avanti... grazie.

----------

## Apetrini

Trovato!!

Su suggerimento di randomaze ho trovato questo 3d, che parla della stessa cosa, anche se io non avevo pensato a nulla, avevo solo sentito la necessità di una cosa del genere...

Quindi resuscito questo 3d, sperando che le persone che sono in grado di fare cio non siano evaporate....

----------

## .:chrome:.

 *Apetrini wrote:*   

> 
> 
> ```
> ottimizzare gli accessi alla memoria configurando opportunamente i meccanismi di prefetching
> ```
> ...

 

oltre a quello che a quanto pare fai già, puoi lavorare su quello che trovi in /proc/sys/vm. puoi provare un kernel con le patch di kolivas. più di tanto non saprei. non ho mai sperimentato troppo perché non mi andava di sconvolgere il sistema

----------

## Apetrini

Stanotte ho ritrovato il 3d 

```
[RFC][PORTAGE] Implementare /etc/portage/package.cflags
```

 che si trova qualche riga piu sotto. Chiedo ai moderatori se è il caso di fondere i due 3d? perche la gente continua a rispondere su questo, ma in quell'altro ci sono già delle idee pratiche su come fare la cosa e mi sembra importante non perderlo di vista.

----------

## Dr.Dran

X chi fosse interessato a sviluppare qualche cosa di buono ecco a voi:

https://forums.gentoo.org/viewtopic-t-280748-start-0-postdays-0-postorder-asc-highlight-perpackage+cflags.html

P.S. Prendete spunto e partecipate attivamente  :Very Happy: 

X quello che mi riguarda sono sempre favorevole alla sperimentazione, ma però sono daccordo con k.gothmog su server e desktop di produzione, + che lavorare sulle cflags o ldflags è meglio ottimizzare i parametri dei dispositivi e utilizzare codice compilato con flag "sicure"  :Wink: 

Ciauz

----------

## randomaze

 *randomaze wrote:*   

> Se non ricordo male FonderiaDigitale voleva implementare qualcosa di simile, e c'é stato anche un thread in cui si discuteva della sintassi da adottare

 

 *Apetrini wrote:*   

> Stanotte ho ritrovato il 3d...

 

Grazie Apetrini, ricordavo quel thread ma sinceramente non ho avuto il tempo di cercarlo!

Adesso faccio il merge dei due thread  :Wink: 

----------

## fctk

ma non esiste già qualcosa di simile? https://forums.gentoo.org/viewtopic-t-280748.html

----------

## Dr.Dran

 *fctk wrote:*   

> ma non esiste già qualcosa di simile? https://forums.gentoo.org/viewtopic-t-280748.html

 

Si è il link che ho evidenziato pure io!   :Very Happy: 

Ma qua nessuno legge correttamente i post   :Wink: 

----------

