Compilazione Unit

[Riccardo Ferrari]

Ho scritto delle unit che compilate e posizionate nelle opportune directories (cioè C:\FPC\3.2.2\units\x86_64-win64\ e C:\FPC\3.2.2\units\i386-win32\) consentono la compilazione dell'eseguibile che le richiama.
Fin qui tutto bene.
Senonché ho scritto un'unit (chiamiamola Alfa) che richiama altre unit. Compilata l'unit principale (cioè Alfa) ritenevo che fosse sufficiente posizionare solo quella nelle directories di cui sopra.
E invece no, compilando un eseguibile che richiama Alfa vengono richieste anche le unit richiamate da Alfa.
Che senso ha? Una volta compilato un EXE, le unit che richiama si potrebbero anche cancellare, l'exe funziona da solo. Invece, se compilo una unit perché deve continuare a portarsi dietro anche le unit che contiene?
Mi chiedo se tra i mille switch che si possono attivare durante la compilazione ce ne sia uno che faccia inglobare le unit richiamate nell'unit principale, in modo da non moltiplicare i file necessari per le compilazioni successive.
Grazie per l'attenzione.

[DragoRosso]

Avevo incominciato ieri a risponderti, poi ero di fretta ho abbandonato.

Non sono certissimo di ciò che scrivo in questa risposta, ma in linea di massima dovrebbe essere così.

Ogni unità viene compilata in maniera diciamo autonoma, ossia il compilato è a se stante e contiene tutto quello che è necessario per riuscirlo a comporre insieme ad altre compilate (cioè "linkarle") per formare un eseguibile.

L'unità dipende dalle unità definite in USES nella sezione Interfaces, che devono quindi essere poi disponibili in fase di link.

Ciò è indispensabile per pensare di riuscire a comporre delle unità modulari, ossia unità che "messe insieme" in una qualsiasi maniera (-> infinite combinazioni) possano formare un eseguibile.

L'alternativa sono le librerie del C, ossia un insieme di oggetti "omogenei" raccolto in un unico file che possono essere usate per lo stesso scopo. Non è possibile creare una libreria per il Pascal per via della sua natura e quindi rimangono solo le .ppu ( o .dcu in Delphi).
In Delphi ci sono ulteriori soluzioni, le ".bpl", che di fatto sono delle DLL e contengono tutte le funzionalità delle unità. Sono usate a runtime e quando settato opportunamente il progetto l'eseguibile non contiene il codice dall'unità compilata ma lo và a richiamare nella ".bpl".

Però ritengo che anche nella soluzione di Delphi, a livello di linker devono comunque essere presenti le unità compilate anche se esistono le estensioni ".bpl".

Quindi rispetto a Lazarus a livello di compilazione o link non cambia nulla.

Ciao

[bonmario]

Ho scritto delle unit che compilate e posizionate nelle opportune directories (cioè C:\FPC\3.2.2\units\x86_64-win64\ e C:\FPC\3.2.2\units\i386-win32\) consentono la compilazione dell'eseguibile che le richiama.

Perché fai questo?
Guarda qui: https://wiki.lazarus.freepascal.org/IDE_Window:__Compiler_Options#Paths paragrafo "Other Unit Files"

In pratica, invece di copiare le unit, basta che:
- vai in Progetto ==> Opzioni progetto
- nella spalla di sinistra vai su Opzioni compilatore ==> Percorsi
- nel primo campo "Altri file unit" aggiungi tutti i percorsi dove vuoi che vada a leggere i sorgenti (.ppu, .pp, .pas, .p) che servono per creare le unit che hai scritto prima. devi aggiungere più diretories, o ti aiuti col bottone che c'è di fianco, o le separi a mano con un "punto e virgola"

In pratica, prima di compilare il tuo progetto, compila i sorgenti di cui hai fatto la "uses" nel tuo progetto, che sono nei percorsi che hai indicato. Le unit appena create, sono poi usate per compilare il progetto

Ciao, Mario

[Riccardo Ferrari]

Ho scritto delle unit che compilate e posizionate nelle opportune directories (cioè C:\FPC\3.2.2\units\x86_64-win64\ e C:\FPC\3.2.2\units\i386-win32\) consentono la compilazione dell'eseguibile che le richiama.

Perché fai questo?
Guarda qui: https://wiki.lazarus.freepascal.org/IDE_Window:__Compiler_Options#Paths paragrafo "Other Unit Files"

Grazie, ma non uso Lazarus. Prima o poi lo farò. Per ora uso solo FPC "liscio"
Che comunque ha la possibilità di indicare posizioni aggiuntive per le unit.
FPC ha quelle posizioni dedicate e metto le unit lì
Grazie per l'attenzione

[Riccardo Ferrari]

Avevo incominciato ieri a risponderti, poi ero di fretta ho abbandonato.

Ti ringrazio per l'attenzione, ma ho abbandonato l’idea.

Sul forum in inglese c’è stata un’ampia discussione, ho capito che non si può fare.
https://forum.lazarus.freepascal.org/index.php/topic,65932.0.html
Non ho capito perché. Alla mia ignoranza informatica si è aggiunta la difficoltà dell’inglese, per cui ho lasciato perdere.

Con l’Italiano vado meglio quindi insisto:
Se compilo un’exe che contiene un’unit, dopo la compilazione l’unit la posso anche cancellare.
Se compilo un’unit che contiene un’altra unit, ottengo due file .ppu e .o, che (credevo) inglobassero le unit richiamate (come l’exe ingloba le unit che richiama).
Quindi ritenevo che come per l’exe quei due (ppu e .o) fossero sufficienti. Invece non solo occorre portarsi dietro TUTTI i ppu delle unit richiamate, ma aver pensato di farne a meno pare che sia una sorta di sacrilegio. Purtroppo la difficoltà della lingua mi ha impedito di capire meglio.

[DragoRosso]

Caspita se ti hanno risposto sul forum internazionale, si sono prodigati.
E' come ti dicevo io, ossia per varie necessità ogni unità produce un oggetto compilato necessario (insieme a tutti gli altri, compresi quelli richiamati) in fase di link.

Però, non vedo le problematiche, rispetto a ciò che mi pare ti dà fastidio "occorre portarsi tutto dietro" ...

Anche se non usi Lazarus ma FPC puro, dovrebbe esserci la possibilità di aggiungere un cartella aggiuntiva per la ricerca dei compilati / sorgenti.

In questo modo, se metti li dentro quello che tu "costruisci", allora sarebbe molto facile "portrarsi dietro" lo cose ... di fatto sarebbe come una libreria a cielo aperto (invece che in formato lib ad esempio).

Ciao e buon lavoro

[Riccardo Ferrari]

Caspita se ti hanno risposto sul forum internazionale, si sono prodigati.

Sì, mi ha stupito la rapidità e la quantità di risposte.
Come ti ho già detto sembra quasi che la mia idea sia un sacrilegio di leso Pascal, forse per quello sono intervenuti in tanti.
Ho capito che non si può fare, ho capito poco perché, ancora meno perché sia un sacrilegio.

Però, non vedo le problematiche, rispetto a ciò che mi pare ti dà fastidio "occorre portarsi tutto dietro" ...
Anche se non usi Lazarus ma FPC puro, dovrebbe esserci la possibilità di aggiungere un cartella aggiuntiva per la ricerca dei compilati / sorgenti.

Si, ma per come sono organizzato preferisco mettere le unit insieme alle altre.
Speravo di metterne meno. Pazienza
In generale tendo sempre a limitare il numero di file, non solo con il Pascal.

[quack]

Se compilo un’exe che contiene un’unit, dopo la compilazione l’unit la posso anche cancellare.
Se compilo un’unit che contiene un’altra unit, ottengo due file .ppu e .o, che (credevo) inglobassero le unit richiamate (come l’exe ingloba le unit che richiama).
Quindi ritenevo che come per l’exe quei due (ppu e .o) fossero sufficienti. Invece non solo occorre portarsi dietro TUTTI i ppu delle unit richiamate ...

La differenza tra la compilazione di un eseguibile e di una unit è che nel secondo caso non viene chiamato in causa il linker. E' quest'ultimo che crea l'eseguibile mettendo insieme il codice macchina contenuto nei vari file .ppu/.o.
La conseguenza di ciò è che i file .ppu/.o di una unit contengono solo il codice relativo alla stessa unit (...più eventuali riferimenti) ma non il codice delle altre unit.

Nessuno ti vieta di posizionare i tuoi files come meglio credi, ma per fare ciò ci sono appositi strumenti (PATH, Package ...)
sicuramente più efficaci rispetto a lavorare con i file .ppu/.o.

[Riccardo Ferrari]

La differenza tra la compilazione di un eseguibile e di una unit è che nel secondo caso non viene chiamato in causa il linker. E' quest'ultimo che crea l'eseguibile mettendo insieme il codice macchina contenuto nei vari file .ppu/.o.
La conseguenza di ciò è che i file .ppu/.o di una unit contengono solo il codice relativo alla stessa unit (...più eventuali riferimenti) ma non il codice delle altre unit.

Non con questa chiarezza, ma ero arrivato più o meno a questa conclusione dopo un paio di giorni di forum.

Continuo a non capire perché non sia disponibile uno switch di linea di comando o l’istruzione di compilazione {$ Qualcosa} che richiama il linker anche per le unit, se è quello, come dici, il problema.

Ci sono decine di switch e ancora più istruzioni di compilazione diverse, una in più …

Scrivo per amor di discussione, ho già rinunciato e le unit sono a posto. Cinque unit in più (che fanno 20 file: .ppu  e .o = 2 file,  64 bit e 32 bit = 2 file, totale 5x2x2=20 file). Sono tanti per chi, come me, viene da lontano, quando i byte erano i byte e se ne apprezzava il valore.

[quack]

Ripeto e chiudo, non solo le opzioni che mancano devi solo imparare ad usare gli strumenti corretti.
Bonmario ti ha già dato le indicazioni su come usare i percorsi, prova ad imparare come funzionano e vedrai che alla fine ti faranno risparmiare un sacco di tempo.
Non ti piacciono i Path, ci sono i Package ...

... Cinque unit in più (che fanno 20 file: .ppu  e .o = 2 file,  64 bit e 32 bit = 2 file, totale 5x2x2=20 file). Sono tanti per chi, come me, viene da lontano, quando i byte erano i byte e se ne apprezzava il valore.

... Mi vengono i brividi solo a pensare di dover spostare i file a mano ...   

[Mimmo]

Non con questa chiarezza, ma ero arrivato più o meno a questa conclusione dopo un paio di giorni di forum.

Continuo a non capire perché non sia disponibile uno switch di linea di comando o l’istruzione di compilazione {$ Qualcosa} che richiama il linker anche per le unit, se è quello, come dici, il problema.

Ciao,
butto anche io i miei 2 penny.
Credo che l'idea possa assolutamente avere un senso in termini generici, in fondo le librerie sono un po' qualcosa di simile, ma credo che sia stato scelto questo approccio, come in tanti altri linguaggi di programmazione, per semplicità e per le prestazioni.
E' una scelta, con vantaggi e svantaggi.

[DragoRosso]

Le librerie sono senza dubbio percorribili (vedi in C o altri linguaggi) ma come giustamente afferma @Mimmo, ci sono problematiche di velocità e anche di compatibilità.

Adesso come adesso, io ricompilo una unit, una qualsiasi unit, e posso usarla con l'ambiente attuale senza fare alcunchè. Con le librerie, ogni volta che compilo una unit devo anche ricordarmi di aggiornare la libreria eventualmente.

Ovvio che le librerie tendenzialmente potrebbero essere quelle di sistema (FPC e LCL ad esempio) e quelle di terze parti che non vengono generalmente mai ricompilate.

Per Delphi hanno deciso che la velocità di compilazione è un fattore importante  (e di fatto è il più veloce compilatore tra quelli che conosco) e quindi tutto viene lasciato così come è non spostando il toolchain con LLVM (e perdendo parzialmente la compatibilità con C++ del RAD).

[nomorelogic]

[...]
Continuo a non capire perché non sia disponibile uno switch di linea di comando o l’istruzione di compilazione {$ Qualcosa} che richiama il linker anche per le unit, se è quello, come dici, il problema.
[...]

il linker deve tradurre un indirizzo dichiarato (nelle unit/librerie) in un indirizzo fisico all'interno di un file binario compilato (.exe/.so/.dll)

che la unit A utilizzi la unit B va bene a tutti, ma fin quì si tratta solo di dichiarazioni

nel caso che i binari ALFA e BETA dovessero utilizzare ambedue la unit A, sicuramente il codice oggetto (.ppu) incorporato nei vari binari non sarà nella stessa posizione fisica (poiché l'elenco delle unit/librerie utilizzate dai due binari saranno necessariamente differenti)

è quindi il linker che risolve gli indirizzi e non può fare altro che operare questa risoluzione proprio su un determinato binario (.exe/.so/.dll) che è per forza di cose diverso da tutti gli altri

l'ho raccontata un po' semplificata ma in fondo il concetto è questo 

nomorelogic


Edit:
errata corrige
in realtà il codice oggetto è nel .o
nel .ppu ci sono altre informazioni necessarie al linker ma non il codice oggetto

[Riccardo Ferrari]

l'ho raccontata un po' semplificata ma in fondo il concetto è questo 

Grazie.
A conclusione della questione ringrazio anche tutti gli intervenuti.