Claudio, il tuo “esperimento” è molto interessante, ma procede dall’alto in basso e non permette, secondo me, di vedere chi effettivamente è caricato da chi.
Ti faccio un esempio semplice.
amsfonts è caricato da amssymb, sempre; quindi effettivamente uno è autorizzato a ritenere che amsfonts dipenda da amssymb. Giusto; Ma proprio per questo amsfonts non dovrebbe mai venire caricato dall’utente, perché quando ha caricato amssymb, senza il quale non dispone dei comandi per i vari simboli, amssymb carica amsfonts che l’utente lo voglia o no; L’albero amssymb -> amsfonts non interferisce con altri pacchetti.
Altro esempio: caricando graphicx, viene caricato anche graphics; se ne deduce correttamente che il primo dipende dal secondo; sì, è corretto, ma la situazione non è simile a quella di amssymb e amsfonts; se carichi graphics, questo non carica graphicx; quindi esiste una dipendenza, ma unilaterale. Se specifichi graphicx, quindi, esso carica ciò da cui dipende, ma a sua volta carica trig (per le funzioni trigonometriche necessarie per le rotazioni e i cambiamenti di scala che richiedono di costruire adeguatamente la matrice di trasformazione dei linguaggi PDF e PS). Si può dedurre che graphicx dipenda da trig. Ma per stabilire come costruire correttamente la matrice di trasformazione deve conoscere con quel “engine” si sta compilando il file e saputolo, carica un opportuno file .def (dvips.def, pdftex.def, xetex.def,…) quindi graphicx dipende da tutti questi file .def. Ma è giusto chiamarle dipendenze?
Quindi il tuo approccio è giusto, ma va spiegato meglio chi chiama chi e \listfiles dà solo l’elenco dei file caricati; per sapere chi ha caricato che cosa, bisognerebbe esaminare di volta in volta il file .log e controllare l’apertura e la chiusura delle parentesi tonde; nel file .log l’apertura di in file è segnalata dal nome completo di percorso del file preceduto da una tonda aperta; la fine della lettura di quel file è segnalata da una tonda chiusa. Fra queste due parentesi possono venire caricati e letti altri file che a loro volta possono… eccetera; solo così si può sapere esattamente chi chiama che cosa e si può costruire un albero delle dipendenze.
Un’altra cosa: le classi standard di solito per ogni opzione caricano un file che ne implementa le funzionalità; non tutte le opzioni si comportano così, ma è frequente. Per esempio book, report e article per ogni opzione di corpo caricano un file opportuno con estensione .clo che sta per class option, anche la posizione delle equazioni e dei loro numeri dipende da due altri file .clo. In questi casi si può dire che book e compagnia dipendano dai file .clo; ma in parte è vero e in parte no: cioè book e compagni dipendo dai file .clo per impostare i font con i loro corpi, ma di volta in volta scelgono solo una di queste opzioni, non tutte contemporaneamente; per questo io non considererei i file .clo come dei prerequisiti al funzionamento delle classi; certo, almeno uno di questi file ci vuole, ma non è necessario che ci siano anche gli altri file .clo per gli altri corpi. Oppure non è obbligatorio che ci siano solo tre file .clo per i corpi; la classe memoir dispone di una collezione di file .clo per i corpi che va, mi pare, da 7pt a 60pt.
Altre dipendenze soo più delicate; sarebbe una cosa utile se tutti i pacchetti che richiedono di essere caricati dopo di altri lo verificassero e nel caso segnalassero un errore; molti autori lo dicono nella documentazione, ma spesso non creano il codice di verifica o non provvedono a caricare inizialmente il pacchetto o i pacchetti necessari. Per certi versi fanno bene, perché se li caricassero con certe opzioni, e poi l’utente li ricaricasse con altre opzioni si avrebbe l’errore di “option clash”.
Insomma è molto difficile scoprire le vere dipendenze, certamente \listfiles non basta anche se è un buon punto di partenza.
Conclusione: il lavoro che hai cominciato è utile ed interessante, ma dovresti almeno corredare il tuo elenco con dei capoversi esplicativi per avvertire i lettori di alcune cose come quelle che ti ho segnalato (che sono ben lontane dall’esaurire la casistica) in modo che il lettore sia messo sull’avviso.
Ottimo lavoro: continua pure e tienici informati. Grazie
Claudio